WireGuard本身默认基于非对称公钥体系完成身份认证与流量加密，而预共享密钥是在原有加密链路之上叠加的第二层对称加密防护，不会替代原有公钥认证逻辑。很多入门教程只给出零散的配置片段，没有讲清前后依赖关系，这篇内容就以最常见的两台Linux设备搭建站点间WireGuard VPN的场景为基础，给出完整可复现的WireGuard预共享密钥：配置示例说明，覆盖从前提检查到故障排查的全流程。
运维人员在机房调试两台站点间的Linux服务器，核验WireGuard VPN基础连通状态。
配置前的基础前提说明
在开始配置预共享密钥之前，首先要确认两台参与VPN连接的设备都已经完成WireGuard的基础部署，内核模块和用户态工具都正常安装，已经生成过各自的公私钥对，并且没有配置预共享密钥的基础WireGuard点对点连接可以正常连通。如果基础连接都没有跑通，直接叠加预共享密钥配置只会增加故障排查的复杂度。
预共享密钥本身要求是256位的完全随机字符串，不要手动输入自定义的弱密码，直接在任意一端的终端执行wg genpsk命令就能生成符合密码学要求的合法密钥，生成之后单独存放在权限为600的独立文件里，不要和原有公私钥文件放在同一个目录下，尽可能缩小密钥泄露的风险面。
服务端侧预共享密钥配置实操
打开已经配置完成的WireGuard服务端配置文件，默认路径一般是/etc/wireguard/wg0.conf，找到对应接入客户端的[Peer]配置段，不要把预共享密钥参数写在全局[Interface]段下面，否则所有接入服务端的客户端都必须使用同一个预共享密钥，不符合最小权限的安全原则。
在对应单个客户端的[Peer]段末尾新增一行参数PresharedKey=，后面直接粘贴你刚才用wg genpsk生成的完整密钥字符串，小黄鸭VPN版本更新指南注意不要在密钥前后加多余的空格、换行或者注释内容，否则WireGuard加载配置的时候会直接判定参数非法，拒绝启动对应接口。
修改完配置之后不要直接重启WireGuard服务，先执行wg-quick strip wg0命令校验配置文件的语法合法性，确认没有参数写错的问题之后，再执行wg syncconf wg0 <(wg-quick strip wg0)命令热加载新配置，这个操作不会中断当前已经建立的WireGuard连接，适合生产环境在线调整配置，不会影响正在传输的业务流量。
客户端侧对应配置调整
客户端侧的配置修改逻辑要和服务端完全对应，打开客户端的wg0.conf配置文件，在填写了服务端公钥的[Peer]配置段里，新增和服务端完全一致的PresharedKey参数，两端的密钥字符串必须完全匹配，哪怕差一个不可见的特殊字符都无法完成后续的加密协商流程。
如果你使用的是Windows、macOS或者移动端的图形化WireGuard客户端，不需要手动修改配置文件，直接打开对应VPN配置的编辑界面，找到预共享密钥的专属输入框，把生成的密钥粘贴进去之后直接保存配置即可，图形化客户端会自动处理参数格式的合法性校验。
配置生效后的验证方式
两端都完成配置加载之后，在任意一台设备的终端执行wg show命令，输出的Peer条目里如果出现preshared-key字段，就说明预共享密钥参数已经被WireGuard正确识别加载，这里的密钥不会以明文形式展示，只会显示掩码标识，不用担心执行命令的时候意外泄露密钥内容。
接下来你可以尝试从客户端ping服务端配置的WireGuard内网虚拟IP，小黄鸭只要之前的基础WireGuard连通性完全正常，配置完正确的预共享密钥之后连接应该可以正常建立。如果发现ping不通，优先回到两端检查预共享密钥的字符串是否完全一致，有没有复制的时候多带了首尾的空格。
常见配置误区与故障定位
很多用户配置完预共享密钥之后发现原有连接直接断开，首先排查是不是把PresharedKey参数写在了错误的配置段，比如服务端错误地把预共享密钥写在了自身的[Interface]段，而不是对应客户端的Peer段，这种情况WireGuard会直接拒绝所有新的连接请求。
还有部分新手误以为配置预共享密钥之后就可以替换掉原来的公钥认证，直接删掉了Peer段里的PublicKey参数，这种配置WireGuard是完全不支持的，预共享密钥只是在原有Noise协议握手的基础上额外增加的一层对称加密保护，不能替代原有非对称加密的身份认证逻辑，缺失公钥参数的配置完全无法正常运行。
在多客户端接入的WireGuard服务端场景下，给每个不同的客户端单独配置专属的预共享密钥，就算其中一个客户端的密钥意外泄露，也不会影响其他接入设备的连接安全，安全边界比全局共用同一密钥的模式要清晰很多，也方便后续单独调整单个客户端的密钥而不用全局同步更新配置。
