机场节点速度慢怎么排查？先排除4种“假慢”

更新于 2026-10-23 · baomayun.online

简答：机场节点速度慢时，先固定同一节点和目标，用经代理端口的 curl 测试真实访问耗时，再检查本地网络、DNS、丢包、MTU 与协议差异；ping 不能直接代表代理链路。

定义：机场节点速度慢，是指通过客户端连接后出现网页打开慢、视频缓冲、下载吞吐低或连接中断，原因可能在本地网络、DNS、代理链路、节点拥堵或目标站点。

先试这一步：30 秒速查，先判断是哪一类慢

本文是第三方使用指南，与相关服务商及客户端开发者无隶属关系。先不要同时更换节点、DNS、客户端和网络；一次只改一个变量，才能知道结果来自哪里。

关键提醒：ping发送的是 ICMP 回显请求，只能测试本机到目标的 IP 层连通性和往返时间；它不会自动经过 HTTP 或 SOCKS 代理端口，因此不能直接证明节点代理链路的延迟或下载速度。Windows 的 pathping同样是对源地址到目标地址的路径进行探测，不能替代经代理端口的应用层测试。可参考 微软 ping 命令文档 与 微软 pathping 命令文档。

第一步：用 curl 测真实代理链路，不要再拿 ping 代替测速

如果客户端提供本地 HTTP、SOCKS 或 mixed 代理端口，优先用 curl 让请求明确经过该端口。下面命令以 Windows 命令提示符为例；example.com只是示例域名，请替换为你实际要访问的目标，127.0.0.1:7890请替换为客户端实际端口。

HTTP 或 mixed 端口

curl -x http://127.0.0.1:7890 -o NUL -sS -w "code=%{response_code} total=%{time_total}s start=%{time_starttransfer}s speed=%{speed_download}B/s
" https://example.com/

SOCKS5 端口

curl -x socks5h://127.0.0.1:7891 -o NUL -sS -w "code=%{response_code} total=%{time_total}s start=%{time_starttransfer}s speed=%{speed_download}B/s
" https://example.com/

目的：-x或--proxy指定代理；time_total表示完整请求耗时；time_starttransfer表示收到首字节前的耗时；speed_download是本次完整传输的平均下载速度。curl 官方文档明确区分了这些字段，并说明-x可以指定 HTTP、SOCKS4 或 SOCKS5 代理。可参考 curl 命令手册。

判定标准：连续测试同一 URL 至少两次，记录返回码、总耗时、首字节时间和平均下载速度。若直连 curl 正常、经代理 curl 明显变慢，才有必要继续比较节点、协议和线路；若两者都慢，应先检查目标网站或本地网络。这里的结果是单个目标、单个时段的观测，不代表长期带宽。

如果命令提示“无法连接代理端口”，先检查客户端是否已启动、端口是否写对、当前模式是否允许本机代理，以及 Windows 防火墙是否拦截。不要把订阅地址、账号或密钥放进公开命令记录。

第二步：排除 DNS 假慢，先分清 fake-ip 与真实地址

DNS 问题常表现为首次打开网页长时间等待、部分域名打不开，或换节点后仍然出现相同域名异常。使用 Mihomo 或兼容配置的客户端时，fake-ip与redir-host的行为不同：官方文档列出的enhanced-mode可选值包括fake-ip和redir-host；在 fake-ip 模式下，域名可能映射到配置的假地址范围，文档示例使用了198.18.0.1/16，所以 Windows 中直接执行nslookup看到198.18.x.x不一定表示 DNS 污染或解析失败。可参考 mihomo DNS 配置文档。

nslookup example.com
ipconfig /flushdns

目的：nslookup查看系统解析结果；ipconfig /flushdns清理 Windows 本机 DNS 缓存。示例域名请替换为实际目标。清理缓存后，关闭并重新打开客户端，再使用同一节点和同一 URL 重测。

检查顺序：

1. 先看客户端当前 DNS 模式是fake-ip还是redir-host，不要把 fake-ip 地址直接当成真实目标地址。
2. 再检查配置中的nameserver、nameserver-policy、proxy-server-nameserver和direct-nameserver是否承担了不同用途。mihomo 文档说明，nameserver-policy可按域名匹配解析服务器，proxy-server-nameserver用于代理节点域名解析。
3. 如果浏览器启用了“安全 DNS”或“通过 HTTPS 使用安全 DNS”，先暂时关闭该功能，避免浏览器绕过客户端 DNS；关闭路径会因浏览器版本变化，应在浏览器设置中搜索“安全 DNS”或“Secure DNS”。
4. 一次只保留一套 DNS 接管方式。系统 DNS、浏览器安全 DNS、客户端 DNS 和 TUN DNS 同时接管时，可能造成结果不一致。

判定标准：若只有某个域名异常，优先比较该域名在不同 DNS 模式下的解析结果；若所有域名都失败，先检查客户端、系统网络和代理端口。若 fake-ip 模式下网页可以正常访问，不要仅因nslookup显示198.18.x.x就认定配置错误。mihomo 的 DNS 处理流程和配置字段可参考 mihomo DNS 解析流程文档。

第三步：检查丢包、路由和 MTU，但别把中间一跳当成最终结论

Windows 的pathping可以统计源地址到目标之间的中间跳延迟与丢包，但它仍然使用 ICMP 探测，不能代表经代理端口的实际路径。下面命令只用于检查直连网络是否存在明显异常；目标主机请替换为你能稳定解析和访问的地址。

ping -n 20 example.com
pathping /n /q 20 /w 1000 example.com

看什么：重点看最终目标是否持续超时，以及丢包是否从某一跳开始并持续影响后续目标。单个中间路由出现星号或较高丢包，不足以证明最终链路有同样丢包，因为路由器可能限制 ICMP 响应。微软文档说明，pathping会向路径中的路由器发送多次探测并计算统计结果，但结果仍取决于返回的探测包。可参考 微软 pathping 命令文档。

初步检查 PMTU 或隧道 MTU

ping -f -l 1472 example.com
ping -f -l 1400 example.com
ping -f -l 1300 example.com

目的：-f设置 IPv4 的“不分片”标志，-l设置数据字段长度。微软文档说明，这组参数可用于排查路径最大传输单元（PMTU）问题。若较大的值持续提示需要分片，而较小的值可以稳定返回，说明直连路径的可用 MTU 可能不足；这不是对代理隧道 MTU 的直接证明，TUN 或 WireGuard 类连接仍需在客户端自身的 MTU 字段中逐项对照。可参考 微软 ping 命令文档。

安全做法：先记录当前 MTU，再只调整一个值并重复同一 URL 的经代理 curl 测试。若网页加载、视频缓冲或长连接在较小 MTU 下改善，保留前后测试时间、节点、协议和目标；若没有改善，恢复原值，不要凭一次 ping 结果长期修改系统网络。

第四步：用单变量对照区分节点、协议和晚高峰拥堵

节点名称中的 BGP、IEPL、IPLC 或协议名称不能单独证明实际吞吐量。客户端显示的“延迟（ms）”通常是某个健康检查 URL 或连接测试的响应时间，不等于文件下载速度；真正比较速度，应使用同一目标、同一设备、同一网络和同一时段的经代理应用层测试。

如果客户端支持节点健康检查，可把它作为筛选工具，但不要把健康检查的低延迟直接写成高速。微软的 PsPing 支持 TCP 延迟测试，但它需要直接可访问的目标地址和端口；它不能替代通过本地代理端口访问真实 URL。若你没有可测试的节点服务器地址或端口，就不要用 PsPing 推断节点质量。

建议记录：测试日期和时段、网络类型、客户端名称与模式、节点、协议、是否启用 TUN、DNS 模式、curl 返回码、time_total、time_starttransfer和speed_download。未核实服务方状态、套餐限制或线路策略时，应写“未核实”，不要根据一次测试下结论。

什么时候换节点，什么时候先改配置

可以按下面顺序收敛问题：

1. 直连也慢：先暂停云盘同步、系统更新和其他下载，重启路由器，改用网线或手机热点复测。
2. 直连正常、所有节点都慢：关闭公司 VPN、系统代理、浏览器代理扩展和其他客户端；确认没有双重代理，再检查 TUN、DNS 接管和规则模式。
3. 经代理 curl 只有某个域名慢：比较其他目标，检查该域名的 DNS、浏览器安全 DNS和规则分流。
4. 只有一个节点或一个协议慢：固定测试条件后换另一个节点或协议，保留前后数据。
5. 仅晚间持续变慢：重复白天与晚间测试；如果差异稳定存在，可能是时段性拥堵，但不能仅凭一次结果确认服务端原因。

完成排查后，可继续查看本站的连接问题排查、设备配置指南和常见问题，按设备继续核对代理接管与网络设置。

常见问题

机场节点延迟很低，为什么下载速度还是慢？

延迟通常只反映某个测试请求的往返时间，不等于持续吞吐量。下载速度还可能受目标站点、远端带宽、协议处理、本地 Wi-Fi 或时段性拥堵影响，应使用同一 URL、同一节点和同一时段的 curl 经代理测试。

ping 能不能直接测出机场节点的真实延迟？

通常不能。ping 使用 ICMP，默认测试的是本机到目标地址的直连路径，不会自动经过 HTTP 或 SOCKS 代理端口。应使用客户端内置测试了解健康检查结果，再用 curl -x 测真实应用层访问耗时。

nslookup 显示 198.18.x.x，是不是 DNS 出错了？

不一定。如果客户端使用 Mihomo 的 fake-ip 模式，域名可能被映射到配置的假地址范围，198.18.x.x 可能是预期现象。应先确认 enhanced-mode，再看网页是否能正常访问，不要只凭 nslookup 的地址下结论。

pathping 中间某一跳丢包，是不是节点一定有问题？

不一定。中间路由可能限制 ICMP 响应但继续转发数据。应观察丢包是否持续影响后续跳和最终目标；同时注意 pathping 测的是直连 ICMP 路径，不是代理端口内的应用层路径。

晚高峰速度慢，换成 IEPL 或 IPLC 节点就一定能解决吗？

不能保证。线路标签不能替代实际测试，应在同一网络、同一目标和相近时间比较多个节点的总耗时、首字节时间、平均下载速度和连接稳定性。

什么时候应该检查 MTU？

如果网页或视频表现为反复卡住、长连接中断，且较小的 ping 数据包正常而较大的不分片探测失败，可以把 MTU 作为线索继续检查。ping -f -l 只能初步观察直连路径 PMTU，不能单独证明代理隧道 MTU 必须改成某个数值。

相关阅读

• 连接问题排查
• 设备配置指南
• 常见问题

参考资料

1. mihomo DNS 配置文档
2. mihomo DNS 解析流程文档
3. curl 命令手册（curl.se）
4. 微软 ping 命令文档
5. 微软 pathping 命令文档
6. 微软 PsPing 文档