代理节点延迟低但速度慢怎么办？
简答：代理节点延迟低，只代表测试请求往返较快，不代表网页、视频或下载一定有高吞吐。先做三组对比：关闭代理测本地基准、固定同一节点与目标测试、再比较其他节点和不同时段；直连也慢查本地，所有节点都慢查客户端或接入网络，只有单节点或晚高峰慢再重点查节点路径与拥堵。
定义：代理节点延迟通常指请求的往返时间，而速度通常指单位时间内持续传输的数据量，二者是不同的网络指标。
先看30秒判断卡：不要先反复换节点
| 测试结果 | 优先排查方向 | 先做什么 |
|---|---|---|
| 直连也慢 | Wi-Fi、网线、运营商接入、设备负载或目标站 | 换网线或手机热点，暂停后台上传下载，再测同一目标 |
| 直连正常，所有节点都慢 | 客户端模式、规则、DNS、TUN、设备性能或整体接入路径 | 回到普通代理，关闭自动切换，一次只改一个设置 |
| 只有一个节点慢 | 该节点负载、路径、协议或节点侧限制 | 固定同一目标，和同组其他节点做对比 |
| 只在晚高峰慢 | 时段性拥堵或共享资源竞争 | 错峰复测，并记录相同节点在不同时段的结果 |
| 只有一个网站或文件慢 | 目标站、CDN、资源分流或单连接限制 | 更换目标验证，不要立即判定整个节点不可用 |
这张表只是排查假设，不是单次测试后的定论。延迟和吞吐分别反映不同方面：RFC 9065 将吞吐描述为单位时间内传输的数据量，并将延迟视为影响应用响应和传输完成时间的指标；RFC 6349则把RTT、瓶颈带宽、缓冲区、路径MTU和丢包等因素纳入TCP吞吐测试框架。可查看RFC 9065和RFC 6349。
三组基准测试：固定条件后再判断问题在哪
- 先测直连基准。关闭系统代理或客户端代理，保持同一设备、同一网络、同一目标地址，记录网页首屏、下载速度或视频缓冲表现。如果直连已经慢，先处理本地网络、后台流量、设备CPU占用或目标站问题。
- 再固定一个节点和一个目标。手动选择一个节点，不使用会自动切换的策略组；网页使用同一页面，下载使用同一文件地址，视频固定清晰度。记录测试时间、节点、模式和结果。
- 最后只改变一个变量。按“换节点→切换规则或全局模式→关闭或开启TUN→对比DNS或IPv4/IPv6”的顺序测试。每次只改一项，并在结果无改善时恢复原设置。
建议至少记录三组结果：直连与代理、一个节点与另一个节点、白天与晚高峰。RFC 6349建议测试前建立RTT和瓶颈带宽基线，并区分单连接与多连接吞吐；普通用户不必完整复现专业测试，但应避免把一次延迟数值当成完整速度证明。
如果客户端使用mihomo，节点健康检查返回的是指定测试地址的延迟或状态，不等于目标网站的大文件吞吐。其API文档列出了节点延迟、测试URL、实时下载速率等字段，可查看mihomo API文档核对测试含义。
按表现分流：网页慢、下载慢和视频卡不是同一个问题
网页打开慢，但大文件下载正常
先区分是域名解析慢、建立连接慢、首字节等待久，还是页面打开后图片和脚本加载慢。可以用浏览器开发者工具观察请求耗时，也可以用curl输出解析、连接、首字节和总耗时。curl官方文档中的time_namelookup、time_connect、time_starttransfer、time_total和speed_download可用于拆分这些阶段，具体参数可查看curl官方命令文档。
如果只有某个域名慢，检查规则是否将主域名或资源域名分到了不同路径；如果多个网站都慢，再回到本地网络、客户端模式和节点对比。
下载慢，但网页访问正常
同一文件至少重复测试两次，并换另一个文件或下载源。只有一个文件慢时，可能是目标站、CDN、单连接策略或资源本身限制；多个目标都慢时，再比较节点、时段和接入网络。
Windows命令提示符可使用：curl.exe -L -o NUL -w "总耗时:%{time_total}s 平均速度:%{speed_download}B/s 首字节:%{time_starttransfer}s" "<目标文件URL>"。PowerShell同样建议明确调用curl.exe，避免被PowerShell命令别名干扰。macOS或Linux将NUL改为/dev/null即可。不要把一次下载结果当成线路固定上限。
视频卡顿或清晰度下降
固定清晰度，分别比较直连、当前节点和另一个节点。如果只有高码率播放卡顿，重点观察持续吞吐、抖动和节点时段表现；如果所有网络都卡，先检查Wi-Fi信号、路由器负载、后台上传和设备省电限制。
实时应用卡顿，但网页很快
实时应用通常更容易受到抖动、丢包、协议和路径变化影响。不要只用网页测速结果判断，应该在相同网络下比较不同节点，并确认客户端是否启用了TUN或其他透明接管功能。
Windows命令怎么用：ping和pathping只能辅助定位
Microsoft文档说明，ping通过ICMP回显请求检查IP层连通性并显示往返时间；pathping会对路径上的中间跳点进行多次探测并统计延迟与丢包。它们可以辅助判断本地链路或路径异常，但这里的“代理下载速度是否足够”仍应使用实际网页、文件或视频测试验证，这是因为ICMP探测与应用层传输并不是同一种流量。
在Windows命令提示符中，可以先测试默认网关，再测试目标域名：
ipconfigping /n 20 <默认网关>ping /n 20 <目标域名>pathping /n <目标域名>
如果默认网关就出现明显延迟或丢包，优先换网线、靠近路由器、切换手机热点或暂停后台流量。如果网关稳定，而代理开启后实际应用才变慢，再对比客户端规则、DNS、TUN和节点。单个中间路由器显示丢包也不能直接证明它是故障点，应观察后续路径和实际应用是否同步异常。可查看Microsoft ping文档和Microsoft pathping文档。
DNS、TUN、MTU和IPv6：只在有对应症状时调整
- DNS：只有域名解析慢、部分域名打不开或规则命中异常时优先检查。改动前记录原设置，改动后用同一域名复测，不要把DNS响应快等同于下载快。
- TUN：只有部分应用不走代理，或普通代理与透明接管表现明显不一致时做对比。mihomo文档说明，TUN可捕获系统流量，并涉及自动路由、DNS接管和按应用路由；因此它会改变流量路径。可查看mihomo入站配置文档。
- MTU：出现特定网站打不开、连接建立后卡住或部分大包传输异常时再考虑。不要直接套用固定数值，每次只改一个方向并保留原值。
- IPv6：只有IPv6与IPv4表现明显不同，或部分应用优先使用IPv6时做对比。验证完成后恢复原设置，避免把临时排查改动当成长期配置。
mihomo文档明确说明，TUN中的MTU会影响极端情况下的传输速率，普通用户通常可以保留默认值。若普通代理已经能完成目标任务，不建议同时启用TUN、改DNS、改MTU和切换IPv6，否则很难知道哪项设置真正产生了影响。
什么时候换节点，什么时候停止继续调参
| 现象 | 更合理的下一步 |
|---|---|
| 直连和代理都慢 | 先换接入网络、暂停后台任务、检查设备负载，再测同一目标 |
| 直连正常但所有节点都慢 | 恢复普通代理，检查规则、DNS、TUN、自动切换和客户端日志 |
| 只有一个节点慢 | 保留固定条件的测试记录，和同组其他节点对比 |
| 只有晚高峰慢 | 错峰复测并记录时段差异，不用白天结果代表全天 |
| 只有一个网站或文件慢 | 换目标验证，优先考虑目标站、CDN或资源分流 |
| 改多个设置仍无变化 | 恢复备份，停止继续叠加参数，联系服务提供方核对节点限制或线路情况 |
建议记录日期时间、接入方式、客户端模式、节点、目标地址、延迟、丢包、首字节时间、平均下载速度和实际体验。只有测试条件一致，结果才适合横向比较。
如果你已经确认问题主要出现在跨境办公的持续连接、线路选择或多设备网络环境，可了解边界云加速的办公网络方案，具体能力与适用范围以官网说明为准。
常见问题
延迟低到多少才算速度快？
没有一个延迟数值可以直接保证速度。延迟反映往返响应，速度还受可用带宽、丢包、拥塞、协议、目标站和单连接限制影响，应使用同一目标做持续传输或实际业务测试。
为什么测速显示很快，下载文件却很慢？
测速目标与文件下载目标可能不是同一服务器、同一线路或同一连接方式。先固定同一个文件地址重复测试，再换节点和时段；如果只有某个文件慢，优先考虑目标站、CDN或单连接限制。
要不要直接切换到全局模式？
不建议把全局模式作为第一步。先确认目标是否被规则正确分流，再临时用全局模式做单变量对比。如果全局模式变快，重点检查规则和DNS；如果仍然慢，问题更可能在本地网络、节点或目标站。
什么时候应该打开或关闭TUN？
当部分应用不走代理，或普通代理与透明接管表现不一致时，才值得做TUN对比。先记录原配置，关闭TUN验证普通代理，再单独开启TUN复测，不要同时修改DNS、MTU和IPv6。
ping有丢包就说明节点坏了吗？
不一定。ping主要检查IP层连通性和ICMP往返时间，某些中间设备可能限制ICMP响应。应观察丢包是否持续到后续路径，并结合网页、下载或视频实际表现判断。
什么时候不该继续调DNS、MTU或IPv6？
如果普通代理已经能稳定完成目标任务，且问题只出现在某个文件、网站或时段，就不建议继续叠加系统参数。先恢复备份，用固定目标和固定节点复测，再决定是否需要联系服务提供方。