注入与原生 HTTP 链

模块最核心的一句话：边缘送来的请求就是 nginx 的普通请求。

Cloudflare 边缘
   │  一条 h2 流（请求头、请求体 DATA）
   ▼
本模块：造一条虚拟连接 → ngx_http_init_connection()
   │
   ▼
nginx 原生 HTTP 处理链
   server_name 匹配 → location 匹配 → rewrite → proxy_pass / return / 变量 / access_log
   │
   ▼
本模块：把响应（含 chunked 解块、trailer）写回那条 h2 流

因此业务配置照旧写 —— 你在 cloudflared 时代为 127.0.0.1:8080 写的 server {}， 现在原样有效，只是「谁把请求送进来」从 cloudflared 变成了模块自己。

注入目标怎么定 ​

注入的虚拟连接是一条真正由 nginx 分配的连接：连接槽来自 ngx_get_connection()、连接池来自 ngx_create_pool()、c->fd 是 socketpair(AF_UNIX) 的真实 fd（只作连接身份载体，数据一个字节 都不经过它），本地地址借自监听器（c->local_sockaddr）。请求字节由模块通过 c->recv 喂进 nginx 的 HTTP 解析器 —— 所以仍然不需要 UDS、不需要额外进程、不需要共享内存。

详细机制（含「为什么绝不能碰 socketpair 的对端」这条不变式）见 注入层。

哪些东西是原生的 ​

两条必须记住的例外 ​

1. 裸 TCP 隧道流：直接丢弃 ​

判据与 cloudflared 一致：流头里 Cf-Cloudflared-Proxy-Src 非空 ⇒ 这条流是 TypeTCP（非 HTTP 服务）。本模块的注入点在 nginx 的 HTTP 链上，承载不了裸 TCP，于是：

• 回 RST_STREAM(REFUSED_STREAM)（0x7），不回 502、不进任何 location；
• 立刻释放流，留一条 ERR 日志。

这是用户定案的规则：宁可响亮失败，也绝不静默降级成 HTTP。

2. 大请求要自己放开 nginx 的门槛 ​

这是 nginx 对普通请求的正常行为 —— 从 cloudflared 换过来时，原来能传的 1 MiB 以上文件 要显式放开：

server {
    listen 127.0.0.1:8080;
    client_max_body_size  512m;
    client_body_timeout   300s;
}

WebSocket ​

location /ws {
    proxy_pass         http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header   Upgrade    $http_upgrade;
    proxy_set_header   Connection "upgrade";
    proxy_read_timeout 3600s;    # 空闲长连接
}

升级由模块完成：请求侧合成 Upgrade / Connection，响应 101 被翻译成 h2 的 200 + cf-cloudflared-response-headers，之后两个方向都是裸字节转发（含 4 MiB 级别背压路径）。

一条流是怎么收尾的 ​