这篇WireGuard Peer配置实操教程面向已经完成基础WireGuard环境部署的用户，完整还原对等节点配置的全流程，附带可直接参考的配置示例，避开网上零散教程里常见的参数错配问题，所有操作步骤都可以在通用的Linux、OpenWrt、Windows等支持WireGuard的设备上直接复现，不需要依赖特定厂商的定制固件。
配置前的核心前提梳理
在开始修改Peer配置之前，你需要提前确认几个基础条件，避免后续排查无意义的问题。首先所有要加入虚拟隧道的节点都已经生成了独立的公私钥对，公钥可以对外分发，私钥必须留在对应节点本地，不能泄露给其他设备。其次提前规划好所有节点使用的虚拟专用网段，不要和任意一侧节点的本地物理内网网段重叠，否则会出现路由优先级冲突，导致本地网络访问异常。最后确认服务端节点的UDP监听端口已经在防火墙放通，所有要主动发起连接的节点都能正常访问服务端的公网地址和对应端口。
服务端侧WireGuard Peer配置示例说明
服务端的配置文件中，[Interface]段是节点自身的基础配置，所有需要接入的对等节点都要以独立[Peer]段的形式追加在配置文件末尾，每一个Peer段对应一个独立的接入节点。第一个必填参数是PublicKey，这里填入的是待接入对等节点的公钥，绝对不能填服务端自身的公钥或者私钥，这是新手配置出错概率最高的位置。
第二个核心参数是AllowedIPs，这里需要填入分配给这个Peer的虚拟IP地址，单个独立节点要使用/32的掩码，比如分配10.0.0.2给这个Peer，就写AllowedIPs = 10.0.0.2/32，如果这个Peer身后还挂载了独立的内网网段，需要把对应的内网段也追加到这一行，后续服务端发往这个内网段的流量才会正确导入对应隧道。如果两个对等节点都有固定公网IP，需要互相主动访问，才需要在Peer段补充Endpoint参数填入对端的公网IP加WireGuard监听端口，以及PersistentKeepalive参数配置隧道保活间隔。
客户端侧Peer配置示例说明
客户端侧的配置逻辑和服务端完全对等，本地[Interface]段填入自身的私钥、刚才服务端分配给它的虚拟IP，可根据需求配置DNS服务器地址。接下来的[Peer]段对应的就是服务端节点的对等配置，PublicKey参数填入服务端的公钥，Endpoint参数填入服务端的公网IP和WireGuard监听端口。
这里的AllowedIPs参数可以根据实际使用需求调整，如果只需要访问服务端侧的虚拟网段和关联内网，就填入对应的网段范围，如果需要把所有流量都通过WireGuard隧道转发，就填入0.0.0.0/0和IPv6的全量网段，配置完成后不要直接启动服务，先核对所有参数有没有拼写错误，避免启动失败。
配置生效后的验证步骤
两边的配置文件修改完成后，先执行关闭旧隧道的指令清空残留路由规则，再重新启动WireGuard服务，不要直接用reload指令加载配置，避免之前的错误路由条目没有被清理，影响后续测试。启动完成后执行wg show指令查看当前隧道状态，所有配置正确的Peer条目都会显示对应的公钥信息，以及最近一次握手的时间戳。
如果Peer条目的最新握手时间为空，说明两个节点之间的密钥协商没有完成，优先排查两端的防火墙规则，确认UDP端口没有被拦截，再核对两边的PublicKey参数有没有填反。握手完成后先尝试ping对端的虚拟IP，能正常响应就说明隧道层已经完全连通，接下来再测试跨节点的内网资源访问，确认流量转发符合预期。
常见配置误区排查
很多新手配置完Peer之后隧道一直不通，大多是几个高频误区导致的。第一个误区是把Peer段的PublicKey填成了自身的私钥，两边的密钥校验完全不匹配，永远不会触发握手。第二个误区是服务端的AllowedIPs给单个Peer分配网段的时候误用了/24掩码，导致多个Peer的路由规则冲突，流量转发逻辑完全混乱。
还有不少用户给处于NAT后面的移动节点配置Peer的时候，忘记添加PersistentKeepalive参数，导致公网侧的NAT端口映射超时之后，服务端完全无法主动访问移动节点身后的资源。如果配置完成后发现本地原本能访问的局域网设备突然无法连通，优先检查客户端侧Peer的AllowedIPs参数有没有把本地内网段也包含进去，把对应网段从AllowedIPs中剔除就可以恢复本地网络的正常访问。
最后需要注意，WireGuard本身没有额外的访问控制逻辑，只要节点的私钥和服务端Peer段登记的公钥匹配，就可以直接接入虚拟网络，所以不要随意把节点的私钥分发出去，也不要在同一个Peer段的AllowedIPs里配置过多无关网段，避免不必要的流量泄露风险。
