密钥匹配解决的核心问题
WireGuard 采用去中心化的对等端模型，客户端与服务端之间不存在传统的控制通道握手。两端公钥的匹配主要解决身份认证与数据通道绑定的问题。只有当通信一端持有的对端公钥与对方实际生成密钥对的公钥一致时，火烧云APP设备才会处理并解密收到的数据包。这种机制将身份验证内嵌于数据面，避免了额外的协商阶段，使得连接建立过程更加简洁且延迟更低。
WireGuard 通过静态公钥实现客户端与服务端间的直接信任绑定，去除了复杂的手shake 过程。
各对象在匹配过程中的职责
在配置中，服务端通常作为发起端或响应端之一，拥有自己的公私钥对，并在其配置文件中通过 PrivateKey 字段持有私钥。对应的 PublicKey 字段则填入对端（如客户端）的公钥。这个公钥字段决定了服务端信任哪个公钥生成的数据包。如果客户端更换了密钥对而未更新服务端的公钥配置，服务端收到的数据包因公钥校验失败会被直接丢弃，连接随即中断。
客户端侧同样持有服务端的公钥，并将其写入自身的 PublicKey 字段。客户端在发送数据时，使用该公钥对明文数据进行加密，确保只有拥有对应私钥的服务端能够解密。这里体现了一种非对称加密的应用逻辑，双方通过预先交换的公钥建立信任，无需在运行时进行复杂的证书验证或会话协商。
路由与流量选择器的角色
公钥匹配成功仅代表数据通道建立，并不代表所有流量都会进入该隧道。是否将特定流量送入 WireGuard，取决于路由表、AllowedIPs 字段以及客户端的网络策略。例如，即使公钥配置正确，若客户端操作系统的默认路由仍指向本地网关，且 AllowedIPs 未覆盖相应网段，相关流量也不会经过 VPN 隧道。这使得 WireGuard 支持部分流量直通，而非强制全部流量入隧。
AllowedIPs 字段在匹配过程中具有双重作用。它既指定了该对等端可以路由到哪些目的地址，也定义了接收源地址的校验范围。如果数据包源 IP 不在 AllowedIPs 列表中，即使公钥正确，该包也可能被拒绝。因此，公钥是身份标识，而 AllowedIPs 是流量边界，二者共同决定了数据的有效流向。
一个只读验证示例
在 Linux 系统中，可通过查看网络接口信息来验证连接状态，而无需修改配置。执行 ip link show dev wg0 命令，观察输出中的 state UNKNOWN 或 state UP 状态，并结合 wg show 命令查看对端的最近握手时间。如果最近握手时间持续更新，说明公钥匹配正确且数据通路正常。若时间静止或报无握手记录，则可能提示公钥不匹配或网络策略阻断，此时应核对两端配置中的公钥字段是否一致。
