§6 cloudflared 侧调优（Tunnel 自己这一段）

状态：已可用。所有默认值/语义取自官方 Run parameters 与 Origin parameters（[DOC]，notes/research/cloudflared-knobs.md）。 ⚠️ 本章只改「边缘 ↔ connector」与「connector ↔ 源站」两段（§2.5 的四跳图）。用户侧的"第一跳"不在本章——那属于 §3–§5 的优选。

6.0 先认清默认值，再谈调优

调优前必须知道默认行为，否则"改了参数"可能只是把官方默认值又写了一遍：

项目	官方默认	说明
出站连接数	每个 cloudflared 实例 4 条 outbound-only 连接	连到至少两个不同数据中心的四台服务器；每个 replica 再 +4 条
边缘 IP 版本	`--edge-ip-version` = `4`	可选 `auto` / `4` / `6`
传输协议	`--protocol` = `auto`	auto 会自动配置 QUIC；无法建立 UDP 时回退 HTTP/2
区域	`--region` 留空 = global	当前可用值只有 `us`
重试	`--retries` = `5`	退避 1 / 2 / 4 / 8 / 16 秒
优雅退出	`--grace-period` = `30s`	收到 SIGINT/SIGTERM 后等待进行中请求
到源站 TCP keepalive	`originRequest.tcpKeepAlive` = `30s`	—
到源站 HTTP/2	`originRequest.http2Origin` = `false`	仅对 HTTPS origin 生效

6.1 连接数与高可用（社区常见误区）

官方事实（[DOC]）：每个运行中的 cloudflared 实例默认建立 4 条仅出站连接，连到至少两个不同数据中心的四台服务器；增加 replica 会再各加 4 条。

⚠️ 官方没有 --ha-connections 参数，也没有可调"单实例连接数"的 config.yml 键——不要照抄社区教程里的这个参数。需要更高可用性时，官方路径是增加 replicas。另外官方明确：replica 不提供 round-robin / hash 流量 steering——不要把它当成"负载均衡策略"来用。

6.2 `--protocol`：QUIC 与 HTTP/2 的正确取舍

取值	传输	端口
`auto`（默认）	自动配置 QUIC；UDP 建连失败时回退 HTTP/2	—
`quic`	UDP	`7844/udp`
`http2`	TCP	`7844/tcp`

🔴 必须纠正一个流传很广的说法：官方文档里没有"QUIC 被限速就必须切 HTTP/2"这条建议。官方给出的只有两种情况：

无法建立 UDP 连接 → auto 自动回退 HTTP/2
UDP 空闲超时导致长连接掉线 → 可测试改为 HTTP/2

所以教程的写法应是：

你的环境	建议	理由
默认	保持 `auto`	让 cloudflared 自适应
防火墙/网络设备阻断 UDP，或 UDP 空闲被过早回收	测试 `protocol: http2`	官方认可的两种情形
需要后量子密钥协商	保持 QUIC	HTTP/2 不支持 PQ（见 6.4）

（防火墙侧要点：QUIC 需放行 7844/udp，HTTP/2 需 7844/tcp。）

6.3 出站地址与区域：`--edge-ip-version` / `--edge-bind-address` / `--region`

--edge-ip-version（默认 4）：可选 auto/4/6。auto 依赖操作系统，以 region lookup DNS 返回的第一种 IP 版本为主集合；双栈环境下另一个集合用于连接失败回退
--edge-bind-address：指定到 Cloudflare 的出站源 IP（多网卡时偏好某接口）；⚠️ 该地址的 IP 版本会覆盖 --edge-ip-version
--region：当前只有 us，会把连接全部走美国数据中心；且 us 使用专用主机名/IP，防火墙需要额外放行

这三者的作用都是"换一条出站路径"，不是"提升速度"的开关。官方没有给出"某组合必然更快"的承诺——实际取决于可达性、路由与防火墙。

6.4 `--post-quantum`：安全与可连接性的取舍

默认：QUIC 隧道连接使用后量子密码（PQC），连接有问题时可回退非 PQ
显式提供 --post-quantum：QUIC 只允许 PQ 密钥协商，不允许回退
HTTP/2 不支持 PQ 密钥协商

→ 这是安全强度 vs 可连接性的开关，不是提速开关。在 http2 路径下无法实现 PQ。

6.5 稳定性与运维旋钮（生产必备）

参数	默认	为什么重要
`--autoupdate-freq`	`24h`	⚠️ 自动更新会重启进程，且不等待新进程接入 → 活动连接可能中断。生产建议 `--no-autoupdate` 并在维护窗口手动升级，或至少安排在低峰
`--no-autoupdate`	未列出	关闭自动更新（Windows / 包管理器安装 / 交互终端本就不启用自动更新）
`--grace-period`	`30s`	优雅重启时降低丢请求概率（代价是退出变慢）
`--retries`	`5`	官方不建议显著增大（会拉长故障恢复窗口）
`--metrics <IP:PORT>`	见 Tunnel metrics 页	暴露 Prometheus 指标（连接/会话/容量）——注意保护监听地址
`--log-directory` vs `--logfile`	—	`log-directory` 按 1 MB 轮转保留 5 份；`--logfile` 不轮转且优先级更高

6.6 QUIC / UDP 的内核与防火墙细节

出现 "failed to sufficiently increase receive buffer size" 日志：官方明确 quic-go 库上报，通常不影响运行，可安全忽略
高带宽特殊环境可以测试手动增大 Linux net.core.rmem_max（官方示例 2500000）——⚠️ 这是示例值，不是推荐基线，官方并未要求所有部署统一修改
若防火墙按 FQDN 过滤 DNS：需允许对 cfd-features.argotunnel.com 的 TXT 查询，cloudflared 才能判断 QUIC UDP datagram 版本，获得最佳 QUIC 性能
官方未给出 Tunnel 专用 MTU 数值，也没有通用 MTU 调优建议

6.7 源站侧参数（`originRequest.*`，别和边缘协议混淆）

键	默认	作用
`http2Origin`	`false`	为 `true` 时尝试 HTTPS + HTTP/2 到 origin，否则 HTTP/1.1。这是 cloudflared→源站的协议，不是 cloudflared→边缘的 `--protocol`
`tcpKeepAlive`	`30s`	向 origin 发送 TCP keepalive 的间隔/超时（不是边缘 QUIC keepalive）

6.8 分工表：哪些问题不该用 cloudflared 参数解决

症状	该动哪里	不该动哪里
国内用户打开慢、转圈	§3–§5 优选（用户↔边缘）+ §7 平台侧	调 `--edge-ip-version`（那是 connector 出站）
回源慢、源站压力大	§7.1 Tiered Cache / Cache Reserve	调 `--protocol`
源站偶发 5xx、超时	源站与 `originRequest.*`	优选
隧道频繁断连	先看 6.1（replica）/ 6.5（自动更新中断）/ 6.6（UDP 被回收）	盲目加 `--retries`

附：cloudflared 的参数文档目前已迁到公开发布线 /tunnel/reference/run-parameters/（与 cloudflare-one 线并存），搜索时两条都要看（§2.3 已提示文档分家）。