- 真实场景：连上了 WireGuard，却无法访问外网
- 先理解一个关键链路
- 最简化的检查思路
- 常见成因与直观表现
- 1. 本地路由冲突或缺失
- 2. AllowedIPs 配置不匹配
- 3. 服务端未启用 IP 转发或 NAT
- 4. 防火墙规则阻断
- 5. MTU 与分片问题
- 6. DNS 不可用
- 逐步排查清单（按推荐顺序）
- 步骤 1 — 验证握手与基本连通性
- 步骤 2 — 测试对端内网与公网 IP
- 步骤 3 — 检查本地路由表与默认路由
- 步骤 4 — 查看 AllowedIPs 配置
- 步骤 5 — 确认服务端 IP 转发与 NAT
- 步骤 6 — 检查防火墙和云安全组
- 步骤 7 — 排查 MTU 与分片问题
- 步骤 8 — 验证 DNS
- 案例演练：一个真实故障与修复过程
- 快速修复捷径（常见场景）
- 避免复发的配置建议
- 结论
真实场景：连上了 WireGuard，却无法访问外网
你打开客户端，显示已连接，Peer 也在线，甚至能 ping 到对端内网地址，但浏览器打不开网页、梯子工具提示“无网络”，这种情况常见且令人抓狂。本文从原理、常见原因、排查流程和快速修复策略逐一展开，帮助技术爱好者在 30–60 分钟内定位并解决大多数“已连接但无网”的问题。
先理解一个关键链路
WireGuard 的连通性至少依赖于三层关系：本地网络栈（接口与路由）、加密隧道（对等端握手与密钥）、以及远端路由/防火墙策略。只要任一环节配置或策略异常，就可能出现“显示已连接但无法上网”的情况。
最简化的检查思路
把问题拆成三步问：接口是否正常？路由是否正确？远端是否允许转发并有有效出口？按顺序排查通常能快速缩小范围。
常见成因与直观表现
下面按症状分组，给出直观的成因与快速判断方法。
1. 本地路由冲突或缺失
表现：客户端可以访问对端内网（例如内网服务器），但无法访问公网或某些目标 IP。原因通常是默认路由未通过 WireGuard 接口，或路由被本地策略覆盖。部分系统在启动后会自动恢复默认路由，导致隧道建立时未获得期望路由。
2. AllowedIPs 配置不匹配
表现：只在访问特定子网时通畅，其他请求无法走隧道。AllowedIPs 在客户端决定哪些流量发往隧道，服务端的 AllowedIPs 决定哪些对端路由如何转发。设置为单个子网或漏写 0.0.0.0/0 会导致无法走全局代理或反之。
3. 服务端未启用 IP 转发或 NAT
表现：客户端的请求达到了服务端（可见流量/握手），但服务端不把流量推到互联网。Linux 服务器若未启用 net.ipv4.ip_forward，或未配置 SNAT/MASQUERADE，会阻止客户端访问外网。
4. 防火墙规则阻断
表现：握手正常，但 TCP/UDP 会话被中断或被拒绝。服务器端或中间链路（VPC 安全组、云厂商 ACL、本地防火墙）可能阻止 WireGuard 隧道传出的流量或特定目的端口。
5. MTU 与分片问题
表现：大文件或 TLS 连接无法建立，加载网页卡住。WireGuard 报文被封装后包长增加，若 MTU 未相应调整，会导致分片丢包或 MSS 问题，表现为只在小包或 UDP 下可用。
6. DNS 不可用
表现：能 ping IP（如 8.8.8.8），但域名无法解析。客户端可能未使用隧道内的 DNS，或远端 DNS 被防火墙拦截。
逐步排查清单（按推荐顺序）
下面的步骤按从本地到远端的逻辑组织，便于快速缩小问题范围。
步骤 1 — 验证握手与基本连通性
确认客户端与服务端已交换密钥并建立握手。若握手失败，先解决密钥、端口和 NAT 问题；若握手成功，继续下一步。
步骤 2 — 测试对端内网与公网 IP
尝试 ping 服务端的内网隧道地址（例如 10.x.x.x）以及一个公网 IP（如 8.8.8.8）。能 ping 内网且不能 ping 公网，说明隧道本身有效，但出口或路由有问题；能 ping 公网但浏览器不能访问则可能为 DNS 问题。
步骤 3 — 检查本地路由表与默认路由
确认系统路由表中，目标流量是否指向 WireGuard 接口。注意操作系统在 VPN 连接后可能不会自动修改默认路由，或存在更高优先级的路由前缀覆盖。
步骤 4 — 查看 AllowedIPs 配置
检查客户端与服务端的 AllowedIPs：客户端若没有包含 0.0.0.0/0，默认流量不会通过隧道；服务端若为单个 IP 绑定，可能无法处理来自多个客户端的流量。
步骤 5 — 确认服务端 IP 转发与 NAT
在服务器上确认 IP 转发已启用（内核参数）并存在相应的 SNAT/MASQUERADE 规则，确保来自 WireGuard 子网的流量被替换为服务器公网 IP 后发出。
步骤 6 — 检查防火墙和云安全组
逐条审查防火墙规则，包括 INPUT/FORWARD/OUTPUT 链。云环境下额外检查安全组与网络 ACL，确保允许 WireGuard 端口（一般 UDP）和转发后的出站流量。
步骤 7 — 排查 MTU 与分片问题
尝试减小接口 MTU 或客户端的 MSS（TCP 最大报文长度），观察大文件或 TLS 会话是否恢复。MTU 问题常造成页面卡住或加载失败。
步骤 8 — 验证 DNS
直接尝试解析域名与访问 IP 地址，确认是否为 DNS 引起。若 DNS 在隧道内不可达，可以在客户端指定隧道内的 DNS 或使用可信的公共 DNS。
案例演练：一个真实故障与修复过程
某用户反馈：显示已连接且能访问内网 NAS（10.10.0.5），但无法访问外网。排查过程如下：
1) 按步骤 2，ping 8.8.8.8 不通；2) 检查路由表，发现默认路由仍指向本地网卡而非 WireGuard；3) 客户端配置显示 AllowedIPs=0.0.0.0/0，但本地策略未替换默认路由；4) 强制添加了指向 WireGuard 接口的默认路由后，公网访问恢复。根本问题是客户端的网络管理器在连接后未正确处理路由优先级。
快速修复捷径（常见场景）
以下是面对常见情形可尝试的“快刀”方法：
- 默认路由问题：临时添加默认路由指向 WireGuard 接口，确认可行后调整客户端配置以持久化该路由策略。
- 服务端无转发：在服务器上开启 IP 转发并添加 MASQUERADE 规则，让客户端流量可走公网。
- DNS 问题：在客户端指定可用的 DNS（隧道内或公有 DNS），并测试域名解析。
- MTU 问题：把接口 MTU 调低 20–40 字节测试，观察是否改善。
- 防火墙拦截：短时间允许 WireGuard 子网通过 FORWARD 链以排除规则干扰，再收紧规则。
避免复发的配置建议
为减少再次遇到“已连接但无网”的概率，可以采取以下常规实践：
- 在服务端统一负责 NAT 和转发，并记录必要的防火墙规则。
- 在客户端配置明确的路由策略（0.0.0.0/0 或细分子网），并处理好本地网络管理器与 WireGuard 的交互。
- 为不同用途设定不同的 AllowedIPs（如只访问内网 vs 全流量代理），避免误操作。
- 把 MTU 和 MSS 作为部署验证项，尤其是当隧道穿越移动网络或双层 NAT 时。
- 及时监控握手状态与流量统计，结合日志快速定位异常。
结论
“已连接但无法上网”通常不是单一原因，而是本地路由、AllowedIPs、服务端转发/NAT、防火墙或 MTU 等因素相互作用的结果。按从本地到远端、从握手到路由再到转发的顺序系统排查，能在较短时间内定位并修复问题。掌握这些要点后，你会发现 WireGuard 的稳定性与灵活性远超同类方案，只需把链路上的每一环都配置好即可。
暂无评论内容