主 题:PO0-RFC-vs-DMIT品川-Speedtest与稳定性评测 初步测评留档
发 布 者:leeFu
标签分类: 测评
时 间:2026-08-04 01:43:47
内容预览:存在局限性,仅供参考浙江电信:PO0 + RFC 日本线路 vs DMIT 品川线路观测窗口:约 4 小时(阶段性短样本,不代表长期表现)测试端:同一台 Mac、同一 Wi‑Fi、同一时段、同一物理网卡 en0测试对象:两条独立 VLESS/Reality 线路;凭据、UUID、公钥等均不公开结论先行:约 4 小时短样本中,DMIT 品川的典型响应和吞吐上限明显更好。PO0 + RFC 的有效带宽首先受华东入口套餐 200 Mbps 限制,RFC JP2 后端的“不限端口速率”无法消除前段瓶颈。两条线路的应用层测试均未断流;DMIT 面板上的短时“丢包”主要是 Komari TCP 探针失败/严格握手标记,尚不能认定为整条线路的真实 IP 丢包。一、评测标准(先说明白)这不是“只看峰值带宽”的评测,而是面向 Claude、Codex、网页和长连接代理的综合评测。以下为本次自定义标准,并非 NodeSeek 官方评分规则。项目权重判断标准长连接与错误率40%HTTPS 成功率、30 秒 SSE 是否中断、是否出现连接重置;失败一次即重点扣分交互延迟与长尾30%TCP 建连、HTTP/HTTPS TTFB 的 P50/P95/最大值;Claude 体感主要看这一项单连接吞吐20%speedtest-cli --single,模拟单个下载、SSE 或大响应连接多连接峰值10%speedtest-cli 默认多连接,反映线路总容量,不直接等于 Claude 体感控制变量两条线路都从同一台 Mac、同一 Wi‑Fi、同一时段发起。为两条线路分别启动临时本地代理,外层连接均强制绑定 en0;未切换 Shadowrocket,也未改变系统默认代理。测试前验证出口:PO0 + RFC:131.143.*.*DMIT 品川:191.222.*.*Speedtest 固定同一服务器,不允许自动
直达链接: https://www.nodeseek.com/post-856104-1
 
 
Back to Top