本文适合已经持有自己服务商 WireGuard 配置的用户。先区分本地 Interface 与远端 Peer，再按 Add Server 的填写流程核对地址、端口、密钥和隧道参数，最后分开检查 AllowedIPs、Global Routing 与 MTU。读完可以判断一个值应填在哪一侧，以及“开关已开启但请求失败”应从哪一层排查。
一、先辨认配置中的 Interface 与 Peer
Shadowrocket（小火箭）中的 WireGuard 类型使用 WireGuard 协议建立隧道。协议通过 UDP 传输，双方用密钥识别身份；它不是填写用户名和密码的连接方式。本文以用户已有的合法配置为前提，参数应来自同一份、分配给当前设备的配置，不能把不同设备或不同 Peer 的字段拼在一起。
常见配置文件分为 [Interface] 和 [Peer] 两段。前者描述本地隧道接口，后者描述远端。进入 Home → 右上角“+”→ Add Server → Type → WireGuard 后，应按字段含义转填，而不是按照配置文件的行号逐行复制；表单分组与可选字段的位置可能随界面调整。
| 配置归属 | 常见字段 | 填写前确认 |
|---|---|---|
[Interface] | PrivateKey、Address、MTU | 描述当前客户端，不是服务器的私钥与公网地址。 |
[Peer] | PublicKey、Endpoint、AllowedIPs | 描述远端身份、连接目的地和允许交给该 Peer 的地址范围。 |
[Peer] 可选项 | PresharedKey、PersistentKeepalive | 仅在原配置提供或实际网络需要时填写。 |
| 解析设置 | DNS | 属于名称解析配置，不是 Peer 公钥，也不是 Endpoint 端口。 |
二、从 Add Server 开始填写地址与密钥
添加时先确定远端地址与端口，再核对两侧密钥，最后检查本地地址及高级参数。以下步骤按填写流程整理；如果界面将 WireGuard 专属选项放在独立分组，仍按相同字段含义对应。
-
选择类型
进入 Home → “+”→ Add Server → Type → WireGuard。先确认 Type，再填写参数，避免在其他协议表单中寻找同名字段。
-
拆分端点
将原配置的 Endpoint 拆为 Address 中的远端主机与 Port 中的端口。例如
vpn.example.com:51820仅用于格式说明：主机是vpn.example.com，端口是51820，实际填写自己的值。 -
核对密钥
PrivateKey 填本地 Interface 私钥；PublicKey 填远端 Peer 公钥。若原配置有 PresharedKey，再填对应字段；不要把客户端自己的公钥当成远端公钥。
-
填写隧道项
将 Interface 的 Address 填入本地隧道地址项，按表单支持的形式保留地址族与前缀信息，再核对 AllowedIPs、MTU 及可选的 PersistentKeepalive。
-
保存并验证
保存后回到 Home，选择刚添加的配置，再检查 Global Routing。首次连接按系统提示确认 VPN 配置授权，随后用明确会走该配置的请求进行测试。
Address 存在语境差异。Add Server 的通用地址栏通常指远端服务器，而 WireGuard Interface 的 Address 指本地隧道地址，例如 10.66.0.2/32。转填时必须看字段所属分组，不能把内网隧道地址填进远端服务器栏。IPv6 Endpoint 在原始配置里常写成 [2001:db8::10]:51820，方括号用于分隔地址与端口，不表示它是本地接口地址。
PrivateKey、PublicKey 和 PresharedKey 都是编码后的密钥值，不能用普通密码替代。WireGuard 密钥是 32 字节，常见 Base64 文本长度为 44 个字符；长度符合只能帮助发现漏字符，不能证明密钥配对正确。复制时尤其注意结尾的 =、隐藏换行和前后空格。
三、AllowedIPs 与 Global Routing 分别控制什么
AllowedIPs 是 WireGuard Peer 的地址前缀集合：发送时参与把目标地址交给哪个 Peer 的判断，接收时也约束该 Peer 可使用的源地址。它不是网站域名列表，不能填 example.com，也不能把 DOMAIN-SUFFIX 规则整行放进去。
Shadowrocket 的规则层与 WireGuard 的 Peer 层是两套判断。Global Routing 选择 Proxy、Direct、Config 或 Scene 等姿态时，决定请求怎样进入策略处理；请求被交给 WireGuard 后，还要满足 Peer 的地址范围和远端转发条件。不能仅修改 AllowedIPs 就认定整个应用的所有流量都会进入该隧道。
| 设置 | 含义 | 适用边界 |
|---|---|---|
0.0.0.0/0 | 覆盖 IPv4 全部地址范围。 | 不包含 IPv6，也不替代 Global Routing 的选择。 |
::/0 | 覆盖 IPv6 全部地址范围。 | 远端与本地配置仍需具备相应 IPv6 能力。 |
10.20.0.0/16 | 只覆盖指定 IPv4 网段。 | 用于受限网段时，不能据此期待公网目标都可经该 Peer 到达。 |
DOMAIN-SUFFIX、IP-CIDR、FINAL | 属于 Config 中的规则关键字。 | 控制请求策略选择，应放在规则配置中，不放入 AllowedIPs。 |
结论：分开检查两层范围
公网请求失败时，先确认该请求实际选择了 WireGuard，再检查 AllowedIPs 是否包含目标地址族与网段。只有其中一层设置正确，仍不足以形成可用的数据路径。
在 Config 姿态下，应检查当前启用配置的规则顺序和最终命中的策略；Direct 姿态不适合验证 WireGuard 出口。Scene 应按当前场景的具体设置判断。若只是隔离规则因素，可在记下原设置后，临时使用 Proxy 并选中待测 WireGuard，完成验证后恢复原姿态。
四、MTU、UDP 端口与 Keepalive 的取值边界
MTU 限制隧道接口可发送的 IP 数据包大小，单位为字节。隧道封装会占用外层数据包空间，所以不能直接把接入网络的 MTU 原样视为隧道可用值。过大的 MTU 可能表现为小请求可用、较大响应停滞，但 DNS、远端转发或网络丢包也可能产生相似现象，不能只凭网页打不开就下结论。
- MTU：优先沿用服务商为当前路径提供的值。外层路径 MTU 为 1500 时，WireGuard 在外层 IPv4 下常按约 60 字节开销估算，在外层 IPv6 下常按约 80 字节估算，1420 是常见起点，不是所有网络都适用的答案。
- Port：必须与 Endpoint 一致。服务器使用其他 UDP 端口时，不能因为示例写了 51820 就改成 51820；网页或 TCP 测试成功也不能证明同一地址的 UDP 通路正常。
- PersistentKeepalive：用于周期性发送保活数据，帮助维持 NAT 映射。原配置为 25 时通常表示 25 秒，不是 25 毫秒；0 通常表示禁用周期保活。
- PresharedKey：是双方额外共享的密钥，两端必须一致。原配置未配置时不要自行生成一个只填在客户端，否则会造成不匹配。
结论：每次只改变一个变量
确认握手与路由后，若只有大响应异常，可记录原 MTU，再将 1420 临时降到 1380 作对照测试；没有改善就恢复原值并继续检查路径。该操作是诊断步骤，不是速度提升保证。
五、从连接授权到网页访问的排查顺序
Home 的连接开关开启，说明客户端开始处理连接，不等于 WireGuard 已完成握手，也不等于 DNS 与远端转发都正常。WireGuard 通常按需握手，因此验证时要产生一条确实交给该配置的请求，再结合可见日志、统计或服务商端状态判断。
- 确认授权与选中项：检查系统 VPN 配置授权是否完成，Home 当前选择是否为目标 WireGuard，而不是另一个保存项。
- 确认请求路径：核对 Global Routing；Config 下检查目标请求是否命中预期策略。排查期间可记录 Settings → On Demand 的状态，避免自动连接规则干扰手动断开、重连的观察。
- 确认 Endpoint 可达：若远端使用域名，先检查该域名能否解析，再检查当前网络是否允许所填 UDP 端口。切换 Wi-Fi 与蜂窝网络可以帮助区分接入网络因素，但测试时应保留相同配置。
- 确认身份配对：检查本地 PrivateKey 是否对应服务端登记的客户端公钥，远端 PublicKey 是否来自当前 Peer。若所有参数看似正确却没有有效握手，应让原配置提供方核对登记关系。
- 确认数据与解析：若已有握手但请求无响应，继续检查 AllowedIPs、远端转发与访问权限；只有域名访问异常时，再检查 DNS 路径，避免先改 MTU 或密钥。
六、转填 WireGuard 参数时的常见问题
PrivateKey 和 PublicKey 能对调试一下吗？
不能。回到原配置，Interface 的 PrivateKey 对应本地私钥，Peer 的 PublicKey 对应远端公钥。若拿到的是服务端配置而非客户端配置，应先取得分配给当前设备的客户端参数，不要直接把两段对调。
AllowedIPs 写了全范围，为什么仍有请求直连？
先在 Home 查看 Global Routing。Config 下由规则决定请求是否进入 WireGuard，Direct 下不会因为 AllowedIPs 是全范围就改走隧道。检查当前规则命中的策略，再确认 IPv4 与 IPv6 范围是否分别覆盖。
原配置的 DNS 应该填进 Address 吗？
不应混填。Address 表示远端地址或本地隧道地址，要按分组区分；DNS 是解析服务器。检查当前 Config 中的 DNS 设置及其可达路径。若 DNS 位于隧道内网，还需确认请求可以通过 WireGuard 到达该地址。
一锁屏再打开就要等很久，改 MTU 有用吗？
先判断是否为闲置后的 NAT 映射失效。核对原配置的 PersistentKeepalive，并在再次发起请求时观察握手恢复情况。MTU 处理的是数据包大小，不负责维持 NAT 映射；若切换网络后持续失败，再检查 Endpoint 与 UDP 通路。
保存排查记录时，建议只记录网络类型、Global Routing 姿态、目标地址族、MTU 和失败阶段。这样能对照“未握手”“已握手但无数据”“只有域名失败”三类问题，避免反复同时修改密钥、路由与解析设置，失去可比较的测试条件。