WireGuard 握手成功，服务却不通

握手完成，客户端显示最近的传输计数器，然而对同一台服务器上某个服务的请求依然失败。这种组合让人困惑，因为隧道确实在工作。尚未被证明的是本地投递：数据包到达了主机，而主机仍需在正确的套接字上接受它，并把它交给有权限应答的进程。请按顺序检查这三个检查点。

在第一处不成立的地方停下来，不要为其余地方加规则。

握手只能证明隧道

WireGuard 的握手在对等端之间建立密钥，并为每个对等端列出的网段授权流量。它没有说明服务器上哪些进程在监听，也没有说明主机防火墙是否会接受发往它自己某个地址的数据包。

最常被忽略的正是最后这个区别：发往主机自身的流量属于本地输入，而穿过主机去往别处的流量属于转发。它们由不同的防火墙链和不同的设置处理。查错链会白白花掉一个下午，还会得到看起来无害的计数器。

读懂监听与路由

在客户端确认服务器隧道地址被路由进隧道。在服务器上确认客户端所用地址上存在套接字，并且其背后的进程正是你想要的那个。

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

监听 127.0.0.1 的进程永远不会应答发往 10.66.0.1 的请求，无论防火墙放行什么。监听通配地址的进程则会应答，除非有规则将其阻断。因此在查看任何规则之前，套接字清单就已经解决了一半的情况。端口和地址共同决定请求能否落地。

把客户端使用的地址与服务器在隧道接口上真正拥有的地址做比较。任一侧的陈旧配置都会产生一个被正确路由到并没有该地址的对等端的请求。

为本地输入而不是转发应用规则

如果数据包到达且套接字存在，剩下的边界就是输入策略。允许转发的规则并不允许本地投递，而限定在某个接口上的规则也可能与你预期的隧道接口名不一致。

用单个放行端口测试目标服务，而不是把主机敞开。然后检查应用自身的授权：白名单、账号要求或绑定到特定主机名，都可能拒绝一个网络已成功送达的请求。

保留证书检查。意外的证书身份说明是另一台主机在应答，而不是需要绕过的障碍。点过警告会掩盖唯一能识别错误服务的线索。

区分名称、大小与身份类故障

按地址能用、按名称不能用，是 DNS 问题，修法在推送给客户端的解析器配置里，而不在防火墙。响应小请求却在大响应上卡住的服务指向包大小与 MTU，那完全是另一种排查。

HTTPS 报错指向错误的主机名，通常意味着请求到了别的服务，往往是因为代理或另一个监听者占着该端口。读取证书主体并与你想访问的主机比对。这个比对不花成本，而且常常直接结束排查。

记录是哪一处失败：套接字、输入规则还是应用策略。这一行能区分网络故障与授权决定。它也能避免下一个人去打开从来不是问题所在的端口。