Python envoy proxy 的 Python 过滤器扩展

不能用，envoy自1.24起彻底移除python过滤器支持，仅可通过wasm+pyodide方案在1.27+版本中运行，但受限于api、标准库及调试能力；go扩展是更轻量稳定的替代选择。

envoy Python 过滤器能用吗？官方不支持，别硬上

Envoy 官方从 1.24 开始明确移除了对 Python 过滤器的支持，envoy.filters.http.python 已被彻底删除，编译时会报 unknown filter name 'envoy.filters.http.python'。这不是配置问题，是代码层面的废弃——连构建脚本都删了。

你看到的旧文档、GitHub 上的 demo 或某些博客里的 python_filter 配置，基本都停留在 1.22 之前。现在强行拉老版本源码编译，会撞上 ABI 不兼容、依赖冲突、gRPC Python binding 错误等一堆隐性坑。

想用 Python 写逻辑？走 WASM + Pyodide 是目前唯一可行路径

Envoy 官方推荐且仍在维护的扩展方式是 WASM，而 Pyodide 可以把 Python 编译成 WebAssembly。这条路不是“直接写 Python”，而是“写 Python → 编译为 .wasm → 注入 Envoy”。性能和启动延迟比原生过滤器高，但它是当前唯一能稳定跑在主流 Envoy 版本（1.27+）上的方案。

• pyodide 不支持所有 Python 标准库（比如 threading、subprocess、os.fork 全不可用）
• 必须用 micropip 安装纯 Python 包，C 扩展（如 numpy、requests）基本不能用
• WASM 模块生命周期受 Envoy 控制，不能主动 hold 请求或开长连接；所有 I/O 必须走 Envoy 提供的 proxy_wasm API（比如 http_call）
• 调试靠 proxy_log 打印，没法 pdb，日志级别要设成 debug 才能看到 console.log 输出

envoyproxy/python-control-plane 跟 Python 过滤器无关

这个仓库名字有误导性：python-control-plane 只是用 Python 实现的 xDS 控制平面（类似 go-control-plane），它不生成、不加载、也不影响任何数据面的 Python 过滤器。你配了它的 gRPC server，Envoy 依然不会认 envoy.filters.http.python。

立即学习“Python免费学习笔记（深入）”；

百度AI搜

百度全新AI搜索引擎

下载

常见误操作：

• 以为启动 python-control-plane 就能启用 Python 过滤器 → 实际只是让 Envoy 能动态获取路由配置
• 在 envoy.yaml 里写了 typed_config 指向 Python 文件路径 → Envoy 启动直接失败，报 filter config not supported
• 把 control-plane 和 data-plane 日志混在一起查错误 → 控制面日志里永远找不到过滤器加载失败的原因

如果真要快速验证逻辑，用 Go 写 HTTP 过滤器更省事

Envoy 对 Go 的支持通过 envoy-go-extension（非官方但社区维护活跃），比折腾 Pyodide 更轻量。一个最简 HTTP 头处理过滤器，50 行内搞定，编译后是静态链接的 .so，无需额外 runtime。

对比点：

• Go 过滤器启动快、内存可控、能访问完整标准库（包括 net/http、encoding/json）
• 调试可直接用 dlv attach，也能打断点
• 不需要预编译 wasm、不用处理 Pyodide 的 import 限制、不依赖浏览器环境模拟
• 如果你只是想改 header、做简单鉴权、转发前加日志——Go 的开发体验远胜于绕路 WASM

复杂点在于：你要接受 Envoy 扩展模型本身是 C++ 主导的，Python 的“胶水感”在这里不是优势，而是约束源头。真正卡住的从来不是语法，而是生命周期、内存模型和线程安全这些底层契约。