主要目标

使用 Clouflare 搭建的节点，在使用默认功能优选节点时，由于使用的人数较多，导致节点能用但延迟较高、不稳定且大量节点无法连接，本期从根本原因出发，按优先级逐步优化，帮你把延迟从 1000ms+ 降到 500ms 以内，确保秒开4K视频，且播放速度稳定。

主要内容

  • 流量链路分析：延迟高的三个根因
  • 修复 ProxyIP：消除大量连接失败节点（必做）
  • CloudflareSpeedTest 本地测速：找到最优 CF IP（必做）
  • 开启「优选IP作为反代IP」：减少一跳中转（强烈推荐）
  • 开启 ECH：减少 GFW 干扰，降低延迟抖动（强烈推荐）
  • 调整优选端口：不同运营商对比测试（可选）

先搞清楚：延迟搞得根源在哪里

优化前必须理解流量走的完整路径，每一跳都会叠加延迟：

1
2
3
4
5
6
7
8
9
你的设备
  ↓ 优选IP 决定入口质量
Cloudflare 边缘节点
  ↓ Worker 运行（10ms CPU 限制）
CF Worker
  ↓ ProxyIP 决定出口质量
ProxyIP 中转节点
  ↓
目标网站

延迟高一般只有三个根因：

根因 典型现象 优化方向
ProxyIP 失效或质量差 大量节点连接失败 更换或自建 ProxyIP
优选 IP 质量差 延迟 1000ms+ 且参差不齐 本地测速找最优 IP
GFW 干扰或 QoS 限速 延迟抖动大、时好时坏 ECH、协议切换、自建出口

准备项

  • edgetunnel 已部署完成，节点可以导入客户端
  • 绑定了自定义域名（.workers.dev / .pages.dev 在国内部分地区被封锁，必须绑自定义域）
  • 客户端使用 Clash Verge Rev（mihomo/Meta 内核）

操作步骤

第一步：修复 ProxyIP（必做，效果最显著）

背景：CF Worker 被 Cloudflare 限制，无法直接访问 Cloudflare 托管的网站，需要 ProxyIP 做中转。ProxyIP 失效是节点大量失败最主要的原因。

进后台 → 设置 → ProxyIP，填入多个备用地址，用换行分隔，失效时自动切换：

1
2
3
4
5
proxyip.cmliussss.net,
cdn-all.xn--b6gac.eu.org,
cdn.xn--b6gac.eu.org,
edgetunnel.anycast.eu.org,
cdn.anycast.eu.org

验证是否有效：https://check.proxyip.cmliussss.net/

预期效果：配置后，连接失败的节点基本消除。

第二步：用本地测速找最优 IP（核心优化）

edgetunnel 默认随机抽取 CF IP，质量完全靠运气。通过本地测速找到对你当前网络延迟最低的 IP，是最直接有效的优化。

下载 CloudflareSpeedTest

Windows

前往 CloudflareSpeedTest Releases 下载 cfst_windows_amd64.zip，解压后得到 cfst.exe，在解压目录打开终端运行。

关闭代理后测速

必须关闭代理，否则测出的是代理服务器到 CF 的延迟，对本机没有意义。

用 HTTPing 模式测速

1
./cfst -httping -tl 150 -sl 5 -p 15
参数 含义
-httping HTTP 测速模式，必须加，过滤掉”TCP 通但 HTTP 代理不可用”的假可用 IP
-tl 150 只保留延迟 150ms 以内的 IP
-sl 5 只保留下载速度 5MB/s 以上的 IP
-p 15 输出前 15 个结果

为什么要用 HTTPing 而不是默认 TCP 模式？TCP 测速会有大量”看起来可用、实际在客户端 Timeout”的 IP，而 HTTPing 模式与 Clash 客户端测速逻辑一致，结果更准确。

实测参考（每次不同，仅示例）：

1
2
3
4
5
6
7
8
9
10
11
IP 地址           延迟(ms)  速度(MB/s)  地区

162.159.45.46     44.10     13.03       NRT（东京）

162.159.44.188    45.34     11.82       NRT（东京）

172.64.53.100     59.02     13.42       NRT（东京）

172.64.52.232     62.29     13.43       NRT（东京）

162.159.38.157    64.46     12.82       NRT（东京）

注意：TCP 测速时 SIN（新加坡）节点可用，但在客户端实测时 Timeout。建议在 Clash 里全部测速后，删掉经常 Timeout 的地区节点。

把测速结果填入后台

后台 → 优选订阅生成 → 模式选「自定义订阅（支持汇聚订阅）」

格式为 IP地址:端口#备注名，每行一个：

1
2
3
4
5
162.159.45.46:443#NRT优选1
162.159.44.188:443#NRT优选2
172.64.53.100:443#NRT优选3
172.64.52.232:443#NRT优选4
162.159.38.157:443#NRT优选5

预期效果：延迟从 1000ms+ 随机分布，降到 400~600ms（NRT 东京段）。

第三步：开启「优选IP作为反代IP」（推荐）

原理：开启后，订阅中的优选 IP 同时也被当作 ProxyIP 使用，入口和出口合并为同一个 IP，减少一跳中转，理论上降低 5~30ms 延迟。

后台 → 优选订阅生成 → 「优选IP作为反代IP」开关 → 开启

开启后重新拉取订阅即可生效。

中国移动:

1
https://addressesapi.090227.xyz/cmcc

中国电信:

1
https://addressesapi.090227.xyz/ct

第四步：开启 ECH（推荐）

原理：ECH（Encrypted Client Hello）是 TLS 1.3 的扩展，对握手阶段的 SNI 字段加密。GFW 无法通过 SNI 识别目标域名，从而减少针对性的 QoS 限速和干扰，降低延迟抖动，提高连接稳定性。

前提：Clash Verge Rev 使用 Meta 内核，已原生支持 ECH，可以直接用。

后台 → ECH 配置 → 开启，填入：

字段 推荐值
ECH DNS cloudflare-ech.com
ECH SNI 留空，或填你自己的伪装域名

保存后重新拉取订阅，节点链接中会自动附加 ECH 参数。

如果开启后节点全部不通，先关掉 ECH 验证基础链路是否正常，再重新测试。ECH 应该在基础链路稳定的前提下开启。

第五步：测试不同端口（可选）

默认端口 443，但不同运营商对不同端口的 QoS 策略不同，可以逐一测试：

后台 → 优选订阅生成 → 「指定优选端口」

端口 说明
443 默认，最通用
2053 联通/移动可能更快
2083 CF 支持的备用 TLS 端口
2087 CF 支持的备用 TLS 端口
8443 备用

建议每个端口单独跑一次测速，对比延迟后选最低的固定使用。

定期维护

CF IP 质量会随时间变化，建议每 1~2 周重新测速一次：

1
2
3
cd ~/cfst
unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY all_proxy
./cfst -httping -tl 150 -sl 5 -p 15

常见问题

测速工具测出来很好，但 Clash 里还是 Timeout

原因：TCP 测速会过滤不掉”TCP 可达但 HTTP 代理不可用”的 IP，必须用 HTTPing 模式。

解决：测速时加 -httping 参数，再把结果填入自定义订阅。

ProxyIP 填了多个，但节点还是失败

原因：填入的 ProxyIP 本身已经失效，或格式有误。

解决：用验证工具 check.proxyip.cmliussss.net 逐一测试，只保留验证通过的地址。

开了 ECH 之后节点全部不通

原因：客户端版本、DNS 配置或链路环境不支持 ECH。

解决：先关闭 ECH，确认基础链路正常后，再用保守配置（ECH DNS 填 cloudflare-ech.com，ECH SNI 留空）重新测试。

测速之后多久需要重测

原因：CF IP 的路由质量会随时间变化，优选结果不是永久有效的。

解决：建议每周重测1-2次，或发现节点明显变慢时重测。

相关资源