线路检测怎么做？从延迟、丢包到实际连接的完整判断方法
简答：线路检测建议按“解析→连通→实际访问”三步进行：先确认 DNS 能解析，再用 Ping 或 TCP 检查延迟与丢包，最后用 curl 验证 HTTPS 是否真正完成连接。单次结果只代表当前网络和当前时刻，不能直接等同于长期稳定性。
定义：线路检测是通过 DNS、ICMP、TCP/TLS 和 HTTP 请求，分层确认目标地址是否可解析、可连接以及能否正常完成实际访问的过程。
先做这 3 步：快速判断线路到底卡在哪里
检测时不要只看一个“可用”或“不可用”结论。建议依次检查域名解析、基础连通性和真实应用层访问；这样能区分 DNS 问题、网络丢包、端口不可达和网页服务异常。
| 检查层级 | 操作 | 重点观察 | 结果含义 |
|---|---|---|---|
| DNS | nslookup example.com | 是否返回 IP | 无结果或超时，优先排查 DNS、域名或本地网络 |
| ICMP | Windows：ping /n 10 example.com | 平均延迟、超时、丢包 | 可观察基础连通性，但不能证明网页或应用一定可用 |
| TCP/TLS/HTTP | curl -sS -o /dev/null -w "code=%{http_code} ip=%{remote_ip} connect=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n" -L --connect-timeout 5 --max-time 15 https://example.com | HTTP 状态码、连接耗时、总耗时 | 更接近真实访问结果，可定位端口、TLS 或应用层问题 |
上表中的 example.com 只是示例，请替换成你实际要检测的域名。Windows 的 ping 会显示回显响应和往返时间，但微软也明确提醒，Ping 不能单独证明整体连接正常；应用层测试更适合确认某个端口或服务是否可用。可参考 Windows ping 命令说明 和 微软 TCP/IP 排查指南。
如何读取延迟、丢包和超时结果
延迟：看多次测试的平均值和波动，不要只看最低值。相同线路在不同时间、网络接入方式和目标位置下可能出现不同结果。若平均延迟不高但偶尔跳到很高，通常比稳定但略高的延迟更容易造成网页卡顿、远程桌面停顿或语音断续。
丢包：Ping 中出现超时只能说明 ICMP 回包没有按时返回，不能直接断言业务流量一定丢包。有些网络设备会限制或降低 ICMP 的优先级，因此应再用 TCP 或 HTTPS 请求复核。若 Ping 丢包，同时 curl 也频繁超时，才更值得检查 Wi-Fi、局域网、出口网络或中间链路。
HTTP 状态码：收到 401、403 或 404，说明请求已经到达服务并获得了应用层响应，不等于线路完全不可用；curl 文档也说明，HTTP 非 200 响应本身不会自动被 curl 当作传输错误。若需要让命令在 400 及以上状态码时返回失败，可使用 -f，具体行为以 curl FAQ 和 curl 参数手册 为准。
超时：先区分连接超时和整体请求超时。--connect-timeout 5 主要限制 DNS、TCP、TLS 或 QUIC 握手阶段，--max-time 15 则限制单次传输总时长；这两个数值是便于排查的参考设置，不是统一行业标准。
按症状分流：检测失败时怎么排查
- 域名无法解析：先运行
nslookup 目标域名，再换一个可信 DNS 或另一条网络测试。如果换网络后能解析，问题更可能在当前网络的 DNS 配置；如果始终没有记录，则需要核对域名拼写和服务端 DNS 状态。不要在未确认域名归属前输入账号、付款或导入配置。 - 解析正常但 Ping 全部超时：不要立即判定线路不可用。继续执行 curl 的 HTTPS 测试；如果 HTTPS 能返回状态码，说明 ICMP 可能被限制。Windows 还可以使用 TCP 端口测试工具，对实际服务端口进行验证。
- 延迟高或波动大：固定测试目标、设备和接入网络，连续测试 3 组，每组间隔几十秒，记录平均值、最大值和超时次数。再关闭后台下载、云盘同步和视频播放，避免把本地带宽占用误判成线路问题。
- curl 连接超时：先把目标换成同一服务的其他已知入口，再分别测试 IPv4 和 IPv6；若只有一种地址族失败，可在客户端或系统网络设置中临时切换验证。若所有目标都失败，回退到基础网络检查，不要反复更换客户端配置。
- 目标显示可用但浏览器打不开：检查浏览器代理、系统代理、DNS 缓存、证书时间和客户端分流规则。随后用无痕窗口或另一浏览器复核；如果 curl 成功而浏览器失败，重点检查浏览器扩展、代理规则和缓存，而不是继续判断线路速度。
移动端、Windows 与 macOS 的实用检测方式
Windows：打开命令提示符，运行 ping /n 10 目标域名；再运行上面的 curl 命令。若系统没有可直接使用的 curl，可先在 PowerShell 中运行 curl.exe，避免与 PowerShell 的别名行为混淆。测试结束后保存命令输出，便于比较不同网络或不同客户端设置。
macOS：打开“终端”，运行 ping -c 10 目标域名，然后使用 curl 命令检查 HTTPS。macOS 的网络服务、Wi-Fi、VPN 和防火墙可在“系统设置→网络”中查看；苹果的 macOS 网络设置说明介绍了这些网络服务的管理入口。
iOS 与 Android：优先使用客户端或浏览器实际访问结果，再在同一 Wi-Fi 和移动数据之间切换复核。移动端不要只根据一次页面加载时间判断线路；应记录网络类型、时间、是否开启系统代理或 VPN、目标是否能完成登录及页面加载。检测过程中不要公开粘贴订阅地址、访问令牌、账号密码或完整配置。
验证标准：什么时候可以认为线路暂时正常
一次合格的线路检测至少应同时满足：域名能稳定解析；连续多次测试没有持续性超时；实际 TCP/TLS/HTTPS 请求能够在合理时间内完成；浏览器或目标应用能够完成你真正要做的操作。这里的“合理时间”应结合目标服务、地区、网络类型和业务要求判断，不建议用一个固定毫秒数替代全部场景。
检测结果只反映当前设备、当前网络、当前时间和当前目标。若要比较两条线路，应保持目标地址、测试设备、接入网络和测试时段尽量一致，并至少重复几次。记录格式可以是：时间｜网络类型｜目标｜DNS｜平均延迟｜丢包｜HTTP 状态｜总耗时｜是否完成实际操作。
如果你只是想确认线路是否能用，优先看实际应用层结果；如果你要定位网络故障，再按 DNS、ICMP、TCP/TLS、HTTP 的顺序逐层缩小范围。这样比只看测速页面或单次 Ping 更容易得到可复现的结论。
常见问题
线路检测只看 Ping 结果可以吗？
不可以。Ping 主要反映 ICMP 回显和往返时间；目标可能限制 ICMP，但 HTTPS 仍然正常，也可能 Ping 正常而实际端口、TLS 或应用层访问失败。至少再做一次 TCP 或 HTTPS 检查。
线路检测显示可用，为什么浏览器还是打不开？
“可用”通常只代表某一次探测请求获得了响应，不代表你的浏览器、代理规则、DNS、证书或登录流程都正常。请先用 curl 复核，再检查浏览器代理、扩展、缓存和客户端分流设置。
延迟多少才算线路好？
没有适用于所有网络和业务的统一阈值。网页访问更应关注总耗时和是否超时，远程桌面、语音或实时协作则更需要关注波动和丢包。比较线路时应使用相同目标和相同网络重复测试。
检测命令会泄露账号或订阅信息吗？
普通域名检测通常只发送目标地址和网络请求，但如果命令中包含带令牌的 URL、Cookie、Authorization 或完整订阅地址，就可能暴露敏感信息。分享日志前应删除域名中的密钥、账号、令牌和配置内容。
页面自动检测卡住了怎么办？
先等待一个明确的超时周期，再刷新或选择手动检测；随后用命令行分别测试 DNS、Ping 和 HTTPS。若命令行正常而页面卡住，问题可能在网页脚本、浏览器扩展或页面请求本身。