本文速览

适用于已经持有自己获授权使用的 WireGuard 配置、需要在 Shadowrocket（小火箭）中核对字段的用户。先区分本机 PrivateKey 与对端 PublicKey，再填写 Endpoint、隧道地址与 AllowedIPs，最后通过 Global Routing 排除规则影响。本文解释参数与排查顺序，不提供连接资料；示例地址仅用于说明格式，不能用于建立实际连接。

一、先分清 WireGuard 配置的两端

WireGuard 配置通常由 [Interface] 与一个或多个 [Peer] 部分组成。前者描述本机的隧道接口，后者描述允许通信的对端。把配置移入 Shadowrocket 时，应按字段的归属填写，而不是把配置中出现的第一个 PublicKey 直接当作服务器密钥。

WireGuard 使用 UDP 传输。Endpoint 的端口由对端配置决定，51820 是常见示例，不是必须使用的固定端口。网页能访问、普通 TCP 端口测试有响应，都不能单独证明当前网络允许这条 WireGuard UDP 通路。

UDP
WireGuard 的传输协议
32 字节
解码后的公钥与私钥长度
51820
本文 Endpoint 示例端口，非强制值

密钥通常以 Base64 文本表示，32 字节的值编码后通常为 44 个字符，末尾带有 =。这个长度只能帮助发现明显的复制缺失，不能证明密钥属于正确的设备或对端。不要把 PrivateKey、PresharedKey 或含这些内容的二维码发到公开讨论区。

二、PrivateKey、PublicKey 与 PresharedKey 怎么对应

字段应使用的内容常见填错点
PrivateKey当前客户端对应的私钥，来自其 [Interface] 部分。误填服务器私钥，或重新生成后没有同步登记客户端公钥。
PublicKey目标 [Peer] 的公钥，即此处要连接的对端公钥。把本机由 PrivateKey 派生的公钥填到这里。
PresharedKey双方额外约定的预共享密钥；只有原配置提供时才填写。一端填有数值而另一端未配置，或与 PrivateKey 混用。
Address分配给本机的隧道内地址，例如 10.66.0.2/32。误填 Endpoint 的公网地址，或占用另一台设备的隧道地址。

PrivateKey 决定本机身份，其对应的客户端公钥需要登记在对端配置中。只在 Shadowrocket 里换一把 PrivateKey，而对端仍保留原客户端公钥，通常无法完成握手。PublicKey 不是密码，也不是随意填写的标签；它必须与实际对端的私钥配对。

复制密钥时保留大小写、加号、斜杠与末尾等号，去掉意外带入的引号和换行。若密钥已经泄露，应更换并同步更新对端登记；仅删除聊天记录不会使旧密钥失效。

三、Endpoint、AllowedIPs、DNS 与 MTU 的作用

Endpoint 是建立加密通路时要联系的外部地址，不是隧道内部地址。IPv4 示例为 192.0.2.10:51820；若使用 IPv6 且地址与端口放在同一文本项中，写作 [2001:db8::10]:51820。若界面分别提供地址和端口输入框，则地址框只填写主机名或 IP，端口框单独填写数字。

设置项含义核对方法
AllowedIPsWireGuard Peer 的地址范围选择及接收来源约束。客户端出站目标需要被相应 Peer 的范围覆盖；同时核对对端是否允许客户端的隧道源地址。
DNS常见配置文件中提供的解析器设置，不属于 WireGuard 握手本身。确认解析器地址在当前路径可达，并检查 Shadowrocket 当前 Config 中的 DNS 设置。
MTU隧道接口可承载的 IP 包大小上限。优先保留提供方给出的数值；大请求卡住而小请求可用时，再单独试调。
PersistentKeepalive空闲时定期发送保活包，间隔单位为秒。需要维持 NAT 映射时，可按配置方要求使用，例如 25；它不负责修复错误密钥。

AllowedIPs 不是 Shadowrocket 的完整分流规则

0.0.0.0/0 表示覆盖全部 IPv4 地址，::/0 表示覆盖全部 IPv6 地址。只填前者不等于同时覆盖 IPv6；只填 10.66.0.0/24 则只覆盖这一网段。范围必须与自己的用途和对端能力一致，不应为了“看起来完整”而直接扩大。

在 Shadowrocket 中，Global Routing 与当前 Config 先决定连接采用哪条路径；当连接交给 WireGuard 对应的出站处理时，还需要满足它的 Peer 地址范围约束。因此，AllowedIPs 中包含某个 IP，并不表示访问它一定会自动选择此 WireGuard 项；规则选中了该项，也不代表缺失的 AllowedIPs 范围会自动补齐。

# 仅用于解释地址格式；不是可直接导入的完整配置。
# 以下地址为示例，不对应实际服务。
[Interface]
Address = 10.66.0.2/32
MTU = 1420

[Peer]
Endpoint = 192.0.2.10:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

1420 是常见 MTU 参考值，不是所有网络的最优值。若握手正常但较大的响应停滞，可记录原值后试用较小值，例如 1380，复测同一请求，再决定是否保留。不要同时改 MTU、DNS 和密钥，否则无法判断是哪项变化起作用。原文件里的 DNS、MTU 等设置也不应被假定会在不同导入方式下全部自动生效。

四、在 Shadowrocket 中添加 WireGuard 的核对步骤

以下以 Home、Config、Settings 结构说明手工添加顺序。不同平台的字段排列与保存按钮位置可能不同，按英文字段含义逐项对应。若自己的资料是多 Peer 配置，不应默认手工添加一个连接项就会完整还原所有 Peer 的选择关系，应先确认本次要使用哪一个对端。

  1. 整理原配置

    区分 [Interface] 与目标 [Peer]，准备客户端 PrivateKey、Address、对端 PublicKey、Endpoint 和 AllowedIPs。原配置有 PresharedKey 时一并准备。

  2. 选择类型

    进入 Home → 右上角「+」→ Type → WireGuard。使用便于辨认的名称，避免与已有连接项同名而误选。

  3. 填写字段

    按本机与 Peer 的归属填写密钥和地址；Endpoint 若拆成地址、端口两项，分别输入。AllowedIPs 保留 CIDR 前缀长度；未提供的 PresharedKey 不自行生成替代。

  4. 保存并选择

    保存后回到 Home，选择刚添加的 WireGuard 项。核对 Global Routing 当前值，再开启连接；首次系统权限提示按设备界面确认。

  5. 验证并还原

    用自己有权限访问、且在 AllowedIPs 覆盖范围内的目标测试。排查结束后恢复日常的 Global Routing 设置；到 Config 核对实际规则引用的策略是否仍指向预期出站。

五、用 Global Routing 区分参数错误与规则影响

诊断时先记录 Home → Global Routing 的当前值。Config、Proxy、Direct、Scene 是路由姿态，不是 WireGuard 的密钥选项。Scene 按已配置的场景行为工作，不宜在尚未确认场景内容时把它当作固定的测试路径。

Config

推荐

按当前 Config 的规则选择策略。DOMAIN-SUFFIX、GEOIP、IP-CIDR 与 FINAL 等规则可能把不同目标交给不同出站；只有命中相应策略的连接才会使用该 WireGuard 项。

适合:规则已经核对完成后的日常分流使用。

Proxy

让进入 Shadowrocket 处理范围的连接采用所选代理路径，用于减少 Config 规则选择带来的变量。仍需确认所选项是目标 WireGuard，且目标地址在其 AllowedIPs 范围内。

适合:短时检查 WireGuard 出站能否访问指定测试目标。

Direct

采用直连路径。此时网页能打开只说明直连条件下可访问，不能作为 WireGuard 配置成功的证据，也不能用来判断该 Peer 的出口状态。

适合:对照设备原有网络的基础连通性。

如果 Proxy 下指定目标可访问、切回 Config 后失败，先检查该目标命中的规则及其策略，不要立即更换 PrivateKey。反之，Proxy 下同样失败，应回到 Endpoint、UDP 可达性、双方密钥和 AllowedIPs 核对。Settings → On Demand 管理按条件触发连接的行为，并不修改 Peer 密钥；排查自动重连干扰时，可先记录其状态，再临时关闭并手动控制连接。

六、握手失败、域名不通与空闲断连怎么查

开关已经打开，为什么还是访问不了？

开关打开不等于 Peer 已完成有效通信。先确认 Home 中选中的是目标 WireGuard 项，再核对 Endpoint 地址与 UDP 端口、客户端 PrivateKey 对应的公钥是否已在对端登记，以及 PublicKey 是否确实来自对端。若有日志或对端握手记录，观察发起测试后是否出现新的有效握手；不要只看连接开关。

有握手记录，却收不到网页内容？

检查双方 AllowedIPs：客户端是否覆盖目标地址，对端是否允许本机的隧道源地址。若目标位于对端后方网络，还要由网络管理方核对转发、防火墙、回程路由及必要的 NAT。握手证明密钥与基础 UDP 通路可用，不保证对端已经提供目标网络的转发能力。

IP 目标可达，域名却提示解析失败？

到 Config 检查当前配置的 DNS 设置和解析器可达性，区分 Endpoint 主机名解析失败与业务域名解析失败。测试裸 IP 时应选择本来就支持 IP 访问的目标；HTTPS 站点可能因证书或虚拟主机要求拒绝裸 IP，不能把这类错误直接归因于 DNS。

放一会儿就不通，重新连接又恢复？

先确认是否发生 Wi-Fi 与移动网络切换，或系统休眠导致连接状态变化。若怀疑 NAT 映射过期，按原配置要求核对 PersistentKeepalive，例如 25 秒；同时查看 Settings → On Demand 是否设置了相应触发条件。保活会增加周期性通信，不能替代网络切换后的实际复测。

提交排查资料时，可以描述失败时间、网络类型、目标地址类别、Global Routing 值及是否出现握手，但应遮去 PrivateKey、PresharedKey 和完整订阅地址。保留每次只改一个字段的记录，比连续替换多组参数更容易找到原因。