理解公钥在连接中的角色
WireGuard的握手使用公私钥材料，每个对等端以所配置的公钥标识身份。它主要用于身份认证和密钥派生，而非直接决定连接可达性。若一端无法识别另一端的公钥，飞机握手将失败，但网络层问题往往更早阻断通信。因此，排查时应区分“协议层拒绝”与“网络层不可达”。
初步只读检查步骤
首先核对服务器实际配置的UDP端口。在服务器端执行ss -uln查看相应UDP套接字是否已绑定；这只反映本机状态。若使用nc -zvu <server_ip> <port>做UDP探测，其输出不能单独证明WireGuard服务可达：UDP没有TCP式握手，WireGuard也可能不回应无效探测报文。应结合两端防火墙规则、抓包及wg show中的最近握手时间核对路径。
网络连接与设备配置场景示意
其次验证密钥对应关系。A端Peer配置中的PublicKey应为B端的接口公钥，B端对应Peer条目则应填写A端公钥，并非让两端Peer.PublicKey字段相同。wg genkey生成私钥，公钥需通过wg pubkey派生；原始公钥为32字节，其标准Base64表示通常为44个字符。字段对应只是静态核对，仍需结合握手及可选PresharedKey的双方配置检查认证情况。
观测结果的边界
若UDP端口可达且公钥正确，但连接仍失败，问题可能在AllowedIPs路由配置。AllowedIPs不仅定义发往对等端的目标地址，飞机还校验接收包源的合法性。例如，客户端配置AllowedIPs=10.0.0.0/8，则该Peer解密后送入接口的数据包，其源地址需属于所配置的范围。混淆目的与源校验范围，易导致流量被丢弃却无报错。
PersistentKeepalive间隔若过大，中间设备可能剪除空闲UDP会话。有需要时可参考25秒这一常见示例，并按实际NAT策略评估；并非所有环境都应开启或设置得更短。它用于保持映射，科学上网不能修复公钥不匹配或服务端不可达等原因造成的握手失败。此外，客户端也可配置ListenPort用于入站连接，但若仅发起出站连接，该字段可省略。
避免常见误判
不要将TCP与UDP同号端口视为同一监听端点。WireGuard仅使用UDP，配置中出现的TCP端口通常属于其他服务。混用协议类型会导致诊断方向错误。所有操作应限于只读检查与参数微调，避免重置网络或重装软件，除非确认本地配置严重错误且已有完整备份。
