主 题：[小白复盘%26教程]DMIT品川154段中转Zouter：回程疑似进入Cloudflare清洗池，改走IPv6后恢复
发 布 者：lk99er
标签分类： 技术
时 间：2026-08-30 18:41:14
内容预览：[实测解决] DMIT品川154段中转Zouter：回程疑似进入Cloudflare清洗池，改走IPv6后恢复如果你和我遇到的情况相同：DMIT品川中转Zouter时，VLESS下载只有5～8MB/s、TUIC完全不通，但两台机器延迟很低、中转其他落地又正常，可以直接跳到第六部分照着配置。如果只想快速确认IPv6能否绕开问题，可以先看第五部分。一、先说结论我的DMIT品川154.*.*.*与Zouter14.*.*.*之间，IPv4回程大概率进入了Cloudflare AS13335的清洗路径。主要表现为：DMIT → Zouter的TCP可以跑到约603Mbps，但重传极高；Zouter → DMIT的TCP只有约46.9Mbps；Zouter → DMIT的UDP接收端为0字节；同一台Zouter改走RivenCloud，双向TCP、UDP均接近千兆；Zouter → DMIT走Equinix Tokyo IXP → Cloudflare；Zouter测试DMIT的191.*.*.* Looking Glass时走GSL，速度正常。由于代理下载数据的主要回程方向正是：Zouter → DMIT → 用户所以Zouter → DMIT只有46.9Mbps，正好解释了实际下载为什么只有5～8MB/s；UDP回程为0，也解释了TUIC为什么完全不能使用。目前DMIT还没有从内部日志正式确认命中了哪条清洗、限速或ACL规则，因此不能说已经100%实锤。但结合双向iperf3、UDP测试、MTR、BGP关系、Looking Glass对照以及Zouter客服结论，“我的DMIT品川154段IPv4入站进入Cloudflare清洗池”是目前概率最高、也最能解释全部现象的原因。最终解决方法不是继续更换协议，而是：用户 → DMIT走IPv4，DMIT → Zouter改走IPv6，Z
直达链接： https://www.nodeseek.com/post-902010-1
发 布 者：lk99er
标签分类： 技术
时 间：2026-08-30 18:41:14
内容预览：[实测解决] DMIT品川154段中转Zouter：回程疑似进入Cloudflare清洗池，改走IPv6后恢复如果你和我遇到的情况相同：DMIT品川中转Zouter时，VLESS下载只有5～8MB/s、TUIC完全不通，但两台机器延迟很低、中转其他落地又正常，可以直接跳到第六部分照着配置。如果只想快速确认IPv6能否绕开问题，可以先看第五部分。一、先说结论我的DMIT品川154.*.*.*与Zouter14.*.*.*之间，IPv4回程大概率进入了Cloudflare AS13335的清洗路径。主要表现为：DMIT → Zouter的TCP可以跑到约603Mbps，但重传极高；Zouter → DMIT的TCP只有约46.9Mbps；Zouter → DMIT的UDP接收端为0字节；同一台Zouter改走RivenCloud，双向TCP、UDP均接近千兆；Zouter → DMIT走Equinix Tokyo IXP → Cloudflare；Zouter测试DMIT的191.*.*.* Looking Glass时走GSL，速度正常。由于代理下载数据的主要回程方向正是：Zouter → DMIT → 用户所以Zouter → DMIT只有46.9Mbps，正好解释了实际下载为什么只有5～8MB/s；UDP回程为0，也解释了TUIC为什么完全不能使用。目前DMIT还没有从内部日志正式确认命中了哪条清洗、限速或ACL规则，因此不能说已经100%实锤。但结合双向iperf3、UDP测试、MTR、BGP关系、Looking Glass对照以及Zouter客服结论，“我的DMIT品川154段IPv4入站进入Cloudflare清洗池”是目前概率最高、也最能解释全部现象的原因。最终解决方法不是继续更换协议，而是：用户 → DMIT走IPv4，DMIT → Zouter改走IPv6，Z
直达链接： https://www.nodeseek.com/post-902010-1
