今日发布文章 · 2026-11-03（待发布）

标题：网络不通先别急着重启：用 ping、mtr 和 DNS 把连通性讲清楚

标签：Linux（按站内现有标签选最贴近的一项）
专栏：选用站内现有相关专栏，不要新建重复专栏

正文：

服务突然连不上了，第一反应往往是重启机器、重启网络。重启有时候确实能好，但它也把现场毁了：到底是本机出网有问题，还是中间某一跳丢包，或者只是域名解析错了，重启之后就再也查不出来了，下次遇到同样的问题还是只能重启。网络排查讲究分层定位，先确认每一层通不通，再决定修哪一层。

第一步先看本机网络是不是正常的。用 ip addr 确认网卡有没有拿到地址，用 ip route 看默认路由指向哪里。如果连网关都 ping 不通，问题大概率在本机或局域网，跟远端服务没有关系，先检查网线、Wi-Fi、网卡状态和本机防火墙规则，别急着去怀疑远端。

第二步用 ping 判断目标通不通，但要会读结果。ping 通说明三层基本可达，ping 不通却不一定是服务挂了——很多服务器会禁 ICMP，ping 不通但业务端口可能是通的。这时可以用 curl -v 或 nc -vz 直接测业务端口，把“网络不通”和“服务没起”区分开。反过来，ping 通但业务不通，就该去看端口监听、防火墙放行和应用日志，而不是继续折腾网络。

第三步，通但不稳定、时快时慢的时候，用 mtr 代替反复 ping。mtr 把 ping 和 traceroute 合在一起，持续向每一跳发包，能看到丢包率和延迟是在哪一跳开始变大的。如果丢包只出现在中间某一跳、而后续跳都正常，往往是那台中间设备对 ICMP 限速，不必当真；如果从某一跳开始丢包一路延续到目标，那一跳附近才是真正值得怀疑的链路。只凭一次 traceroute 的某一跳超时就下结论，很容易冤枉无辜节点。

第四步别忘了 DNS。不少“连不上”其实是解析错了：域名指向了旧 IP，或者解析到了不通的地址。先用 getent hosts 域名 或 dig 域名 看看解析结果是不是预期的地址，再对比换一个 DNS（比如直接用 dig @8.8.8.8）是不是结果不同。如果解析结果本身就不对，改应用配置、重启服务都没有用，得先修 DNS 记录或本地 hosts。本地还有一层容易被忽略：/etc/resolv.conf、systemd-resolved 的缓存和 nsswitch 的解析顺序，都可能让“明明改了记录却还是旧地址”。

最后，把排查过程按顺序记下来：网关通吗、目标 ping 通吗、业务端口通吗、mtr 在哪一跳变差、DNS 解析结果对吗。每一层只回答通或不通，不猜、不跳步。网络问题最怕的就是凭感觉换配置，改完好了也不知道为什么好，下次复发还得从头来。分层定位花的时间看着多，实际上是把一次故障变成可复用的排查经验，这才是排查真正的收益。

（全文约 850 字，原创，未复制粘贴往期内容。主题与 2026-10-26 Docker Compose、2026-10-27 curl、2026-10-28 df/du、2026-10-29 ss/lsof、2026-10-30 Shell 调试、2026-10-31 权限、2026-11-01 systemctl、2026-11-02 定时任务的文章主题均不同，不重复。）