Wasm 已在 NGINX Unit 1.31+ 中正式支持，作为用户态沙箱化应用逻辑单元，可执行 JWT 校验、响应重写等 L7 处理；而标准 Nginx 官方主线不支持 eBPF，因其纯用户态架构无内核接口。
Wasm 已在 NGINX Unit 中落地，eBPF 则无法直接用于标准 Nginx（nginx.org 官方主线）——它不支持内核态扩展，也不提供 eBPF 加载接口。
NGINX 官方主线不支持 eBPF
eBPF 必须运行在 Linux 内核中，而标准 Nginx 是纯用户态进程，所有网络 I/O 由内核通过 socket 接口完成。它既没有内核模块机制，也不暴露 eBPF 程序加载点。试图向 nginx 主进程注入 eBPF 字节码会失败，因为：
-
nginx不调用bpf()系统调用，也未链接 libbpf 或 bcc - 没有类似 Cilium、Katran 那样的 eBPF 编排层
- 任何“Nginx + eBPF”方案实际都是绕开 Nginx 的独立旁路系统（如用 XDP 拦截流量后转发给 Nginx），并非 Nginx 自身能力
WebAssembly 在 NGINX Unit 中已可用（非传统 nginx）
NGINX Unit 1.31+ 支持 WebAssembly 模块作为应用逻辑单元，但它和传统 nginx（即 nginx.org 发布的 http 服务器）是两个不同项目。Unit 是一个通用应用服务器，其设计目标之一就是让 Wasm 模块参与 HTTP 处理链：
- Wasm 模块可实现请求预处理（如 JWT 校验）、响应重写、路由决策等，通过
unitd的配置挂载到特定 location - 模块必须导出符合
__wasi_snapshot_preview1ABI 的函数，如_start和 I/O 相关导入 - 不支持 WASI I/O 以外的系统调用（如文件读写、网络连接），这是沙箱安全边界
- 编译时需指定 target：
wasm32-wasi（推荐）或wasm32-unknown-unknown（需自行实现 syscall shim）
示例配置片段（config.json）：
{
"listeners": {
"*:8080": {
"pass": "applications/wasm-auth"
}
},
"applications": {
"wasm-auth": {
"type": "wasm",
"processes": 2,
"limits": {"memory": "64M"},
"module": "/path/to/auth.wasm"
}
}
}
Wasm vs eBPF：适用层级完全不同
把 Wasm 和 eBPF 并列讨论“谁更适合 Nginx”，本质是混淆了协议栈层级：
- eBPF 运行在内核，能操作
sk_buff、修改包头、做 L4 负载均衡或 DDoS 检测，但无法解析完整 HTTP/2 header 或执行业务逻辑（如 RBAC 决策） - Wasm 运行在用户态沙箱，天然适合 L7 应用逻辑：它能拿到完整的 HTTP 请求 body、headers、method，并返回修改后的 response，但不能触碰 socket 底层
- 二者不是替代关系，而是互补：eBPF 做前置过滤（如限速、ACL），Wasm 做精细化策略（如 OIDC 认证、AB 测试分流）
真正可行的组合路径是：eBPF（XDP/TC）→ 用户态代理（如 Envoy 或自研）→ Wasm 模块处理 → 后端服务。NGINX Unit 只参与最后一环。
别忽略 Wasm 模块的冷启动与 ABI 兼容性陷阱
Wasm 模块在 Unit 中按需加载，首次请求会有毫秒级延迟（JIT 编译 + 内存初始化）。更隐蔽的问题是 ABI 锁定：
- Unit 当前只支持 WASI
snapshot_preview1，不支持更新的preview2（含 component model） - Rust 编译需加
--target wasm32-wasi -C link-arg=--no-entry，否则start函数冲突 - C/C++ 项目若用 Emscripten，必须禁用
EMSCRIPTEN宏并手动实现__wasi_args_get等 stub，否则启动失败报undefined symbol - 模块更新需 reload Unit 配置，无法热替换 —— 这和动态 Lua 模块有本质区别
如果你正在评估 Wasm 是否能替代 ngx_http_lua_module，先确认是否接受这些约束：无全局状态共享、无原生 socket、每次调用都是无状态字节流处理。
