如何修复 Chrome 中的 ERR_ADDRESS_UNREACHABLE

网络中级 7 分钟阅读发布于 2026 年 7 月 17 日

什么是 ERR_ADDRESS_UNREACHABLE？

ERR_ADDRESS_UNREACHABLE 是 Chrome 的一个网络错误，表示浏览器完全无法到达目标 IP 地址。它与 ERR_CONNECTION_REFUSED（有机器响应但没有服务监听该端口）和 ERR_CONNECTION_TIMED_OUT（数据包石沉大海、没有任何响应）截然不同。出现 ERR_ADDRESS_UNREACHABLE 时，是网络本身告诉 Chrome：目标不可达。

其底层信号通常是路由器——或本机网络协议栈——返回的 ICMP "Destination Unreachable"（目标不可达，类型 3）报文。由于故障发生在应用层之下，对端的服务器可能完全正常，问题出在你和它之间的路径上：网络接口可能已断开、路由可能缺失、防火墙可能屏蔽了整个网段，或 ARP 缓存中保存了过时的硬件地址。

下面六个步骤按你最容易遇到的顺序，从最简单的本地检查到更深层的路由和 ARP 问题逐一排查。

常见原因

ERR_ADDRESS_UNREACHABLE 几乎总是源于以下六个根本原因之一。在开始诊断前，先用此表快速定位方向。

根本原因	典型场景	排查位置
网络接口断开	Wi-Fi 掉线、网线拔出、VPN 隧道塌陷	系统网络状态、`ipconfig` / `ip addr`
目标主机离线	目标 IP 对任何流量都不响应	用 `ping` 测试目标 IP
防火墙屏蔽网段	系统或云防火墙丢弃整个 IP 段	ufw、firewalld、安全组
路由缺失或错误	路由表中没有到达目标网络的路由	`route print`、`ip route`
VPN 或代理路由错误	流量被送入失效隧道或错误网关	VPN 客户端、系统代理设置
ARP 缓存过时	缓存的 MAC 地址与真实设备不符	`arp -a`、`arp -d`

步骤 1：检查网络连接

在追查复杂的路由问题之前，先确认最基本的事实：你的机器是否真的在线，正确的网络接口是否启用？Wi-Fi 掉线、网线断开，或后台崩溃的 VPN 隧道，是 ERR_ADDRESS_UNREACHABLE 最常见——也最令人尴尬——的原因。

# Windows
ipconfig /all

# Linux
ip addr show

# macOS
ifconfig

查找拥有有效 IP 地址且链路活跃的接口。如果主接口已断开，或持有 APIPA 地址（Windows 上为 169.254.x.x），说明系统没有任何可用路由，所有目标都"不可达"。先重新连接网络、重启接口或重连 VPN，再继续排查。

步骤 2：Ping 目标 IP 地址

确认本机连通性正常后，测试目标 IP 本身是否可达。直接 ping IP 可以排除 DNS 的干扰，从而区分是路由或可达性问题还是名称解析问题。

# 按 IP ping（Windows 默认发 4 个包；Linux 持续 ping 直到 Ctrl+C）
ping 203.0.113.10

# Linux/macOS 限制发送次数
ping -c 4 203.0.113.10

如果 ping 返回 "Destination host unreachable"，说明故障在路由或本地网络——继续排查防火墙和路由步骤。如果返回 "Request timed out"，说明路径存在但主机未响应（可能离线或丢弃 ICMP），这是另一类问题。如果按 IP ping 成功但浏览器仍失败，则问题在更高层：检查 DNS 是否解析到了错误 IP。

步骤 3：检查防火墙规则

配置为丢弃整个网段或 IP 段的防火墙，会让目标看起来不可达。这在云安全组和企业终端防护中尤其常见。检查本机和目标机器上的防火墙：

# Windows 防火墙
netsh advfirewall firewall show rule name=all | findstr "203.0.113"

# ufw (Ubuntu)
sudo ufw status verbose

# firewalld (CentOS/RHEL)
sudo firewall-cmd --list-all

# iptables
sudo iptables -L -n

查找覆盖目标 IP 或其子网的 REJECT 或 DROP 规则。在云平台（AWS、Azure、GCP）上，安全组相当于第二道防火墙——在那里屏蔽的子网会产生同样的不可达症状。临时放行目标 IP 后再测试。

步骤 4：验证路由表

如果防火墙没有问题，下一个嫌疑对象就是路由表。当没有到达目标网络的有效路由时，ERR_ADDRESS_UNREACHABLE 经常出现——例如 VPN 断开后留下损坏的默认路由，或从未添加的静态路由。查看活动路由：

# Windows
route print

# Linux
ip route show

# macOS
netstat -rn

找到默认路由（Windows/Linux 上的 0.0.0.0 条目），确认它指向一个存活的网关。追踪 Chrome 流量到达目标的实际路径：

# Linux：询问内核会使用哪条路由
ip route get 203.0.113.10

如果该命令报告 "Network is unreachable" 或指向失效网关，你就找到了原因。添加或修复路由——例如恢复缺失的默认路由，或重新添加到目标子网的静态路由。

步骤 5：检查 VPN 和代理设置

VPN 和代理会改写流量的去向，因此是突发"不可达"错误的主要原因。崩溃后未清理的 VPN 客户端可能留下指向已不存在隧道的默认路由，导致每个数据包都被送入虚空。同样，配置为转发到离线网关的代理也会让目标不可达。

# 检查代理环境变量
echo $http_proxy $https_proxy $all_proxy

# Windows：列出活动代理设置
netsh winhttp show proxy

在 Windows 上，打开设置 > 网络和 Internet > 代理，禁用任何不再有效的手动代理。如果涉及 VPN，完全断开并重新连接，或暂时禁用以观察可达性是否恢复。不包含目标子网的分流（split-tunnel）VPN 也会产生此错误。

步骤 6：刷新 ARP 缓存

ARP（地址解析协议）将 IP 地址映射到本地网络上的 MAC 地址。如果某设备的 IP 地址已变更，但本机 ARP 缓存仍保存旧的 MAC 地址，发往该 IP 的流量就会送到错误的硬件地址，目标因此看起来不可达。这在更换路由器、重新分配 IP 或切换到新网关后很常见。

# 查看 ARP 缓存
arp -a

# Windows：清空整个 ARP 缓存
arp -d *

# Linux/macOS：删除指定条目
sudo ip neigh del 203.0.113.1 dev eth0
# macOS
sudo arp -d 203.0.113.1

清空后，下一次连接会强制发起全新的 ARP 请求，用正确的 MAC 地址重建映射。如果清空 ARP 缓存后可达性立即恢复，说明过时的硬件地址就是元凶——在 IP 频繁变更的系统上，可考虑缩短 ARP 缓存超时时间。

网络诊断命令

这些命令构成一套完整的可达性工具集。按顺序运行，可精确定位到达目标的路径在哪里中断。

# 1. 测试到目标 IP 的基本可达性
ping -c 4 203.0.113.10          # Linux/macOS
ping 203.0.113.10               # Windows

# 2. 追踪每一跳，找出数据包在哪里停止
traceroute 203.0.113.10         # Linux/macOS
tracert 203.0.113.10            # Windows

# 3. 查看活动连接和监听端口
netstat -rn                     # 路由表（所有系统）
sudo netstat -tlnp              # 监听的 TCP 端口（Linux）

# 4. 检查并管理 ARP 缓存
arp -a                          # 查看缓存（所有系统）
arp -d *                        # 清空缓存（Windows）
sudo ip neigh flush all         # 清空缓存（Linux）

如果 traceroute 在某一跳停止响应，那一跳就是可达性中断之处——通常是防火墙、失效网关或 VPN 隧道的边界。结合步骤 4 的路由表检查，确认本机是否甚至拥有到达该跳的路由。

快速参考：原因与修复

症状	根本原因	修复方法
立即返回 "Destination host unreachable"	没有到达该网络的路由	检查 `route print` / `ip route`；修复默认路由
仅在 VPN 断开后失败	残留的失效隧道路由	重连或完全禁用 VPN
仅某个网段失败	防火墙丢弃该 IP 段	在 ufw/安全组中放行该子网
原本正常，更换设备后失效	ARP 缓存条目过时	运行 `arp -d` 清空缓存
持有 APIPA 地址（169.254.x.x）	无 DHCP 租约/接口断开	重连网络或重启接口
按 IP ping 成功，浏览器失败	DNS 解析到错误 IP	刷新 DNS；核对解析到的 IP

常见问题

ERR_ADDRESS_UNREACHABLE 和 ERR_CONNECTION_REFUSED 一样吗？

不一样。ERR_CONNECTION_REFUSED 表示有机器响应但没有服务监听该端口；ERR_ADDRESS_UNREACHABLE 表示网络根本无法把数据包送达目标 IP——没有任何机器有机会响应。两者需要的修复方法完全不同。

为什么只有一个网站出现这个错误？

当仅某个目标不可达而其他都正常时，原因通常与该 IP 的路径有关：防火墙规则屏蔽了它的子网、为其网关保存了过时的 ARP 条目，或仅覆盖该网络的路由有问题。使用 traceroute 找出到达该 IP 的路径在哪里中断。

VPN 会导致 ERR_ADDRESS_UNREACHABLE 吗？

会，而且很常见。崩溃后未清理的 VPN 可能留下指向失效隧道的默认路由，使所有目标都不可达。不包含目标子网的分流 VPN 会让仅该子网不可达。完全断开并重连 VPN，或禁用以测试。

刷新 ARP 缓存总能解决问题吗？

仅当过时的 MAC 地址是原因时才有效——通常发生在本地网段更换路由器或网卡之后。如果问题是路由缺失或防火墙屏蔽，刷新 ARP 无济于事。请先用上述诊断命令确认 ARP 缓存是否为元凶，再据此处理。

总结

ERR_ADDRESS_UNREACHABLE 是路由层面的故障：无论对端服务器是否正常，Chrome 都无法把数据包送达目标 IP。按顺序完成这六个步骤——验证本机连接、ping 目标、检查防火墙、查看路由表、复查 VPN 和代理设置、刷新 ARP 缓存——你几乎总能找到路径中断之处。诊断命令提供了一种可复现的方式，精确定位可达性丢失的那一跳，从而修复真正的病因，而不是盲目猜测。