Shadowrocket WireGuard 参数详解:Private Key、Public Key、Address 与 MTU 填法

WireGuard 参数先分清本机与对端

WireGuard 使用密钥对识别通信双方。每一端都有自己的 Private Key 与由它派生的 Public Key：Private Key 留在所属设备，Public Key 交给通信对端登记。因此，服务商发来的客户端配置中，[Interface] 与 [Peer] 不是同一类信息，不能只看见 Key 就互相替换。

对 Shadowrocket 而言，本机 Private Key 用于证明本机身份，Peer 的 Public Key 用于确认远端身份。服务端还需要登记与本机 Private Key 对应的客户端 Public Key。如果自行换了一把 Private Key，却没有同步更新服务端登记，复制其余参数也不能建立正确的通信关系。

Private Key、Public Key 与地址字段的对应关系

下面按标准 WireGuard 配置字段说明对应关系。Shadowrocket 编辑页的字段排列可能随界面调整而变化，核对时以字段含义为准。尤其要区分 Address 与远端服务器地址：前者是隧道内部地址，后者来自 Endpoint，两者一般不相同。

Private Key 应按敏感凭据保管。向他人描述故障时，可以提供报错文字、网络类型和不含凭据的字段名称，不应贴出完整私钥、Preshared Key 或订阅链接。公钥本身不承担私钥的保密作用，但也不必在公开记录中附带账户与地址信息。

在 Home 添加 WireGuard 的录入顺序

先准备自己的完整配置资料，再进行录入。只有一个 Endpoint 或一个公钥，并不足以拼成可用配置；服务端登记的客户端身份、分配地址和允许访问范围都要相互对应。以下以手动添加为例，界面词保留英文。

1. 选协议

   进入 Home → 右上角“+”→ Type → WireGuard。先选择类型，再填写字段，避免把 WireGuard 参数留在其他协议的编辑页中。

2. 填远端

   将 Endpoint 的主机部分填入服务器地址字段，将端口填入 Port。例如资料写成 vpn.example.com:51820 时，主机与 51820 分开填写；这是格式示例，不是可用连接信息。

3. 核对密钥

   填写本机 Private Key 与远端 Public Key；有 Preshared Key 时一并填入。逐项对照原资料，检查复制时是否多带了引号、空白或字段名称。

4. 填内部地址

   按资料填写 Address，并保留要求的前缀长度。IPv4、IPv6 地址都按实际分配处理，不因设备当前连接的是 IPv4 网络就删除配置里的 IPv6 信息。

5. 保存并测试

   核对 MTU 等可选参数后保存，回到 Home 选择该条目。在可控的短时测试中将 Global Routing 设为 Proxy，再打开连接开关；测试结束恢复平时使用的 Config 等姿态。

如果条目由已有 Subscribe 订阅生成，先确认订阅中确实包含 WireGuard 条目。订阅更新可能重新写入由订阅管理的字段，手动改动前应保留原始资料，并记录改了什么。不要为了保留一次试验参数而反复修改整个订阅，也不要把完整订阅凭据写进排障截图。

Address、AllowedIPs 与规则分流不是同一层

Address 是本机隧道接口的内部地址。示例 10.66.0.2/32 中，/32 表示一个 IPv4 主机地址，不表示远端 Endpoint，也不意味着所有网络流量都会自动进入隧道。地址通常与服务端针对该客户端的配置对应，随意改成 /24 并不能修复连接问题。

标准 WireGuard 配置中的 AllowedIPs 关联 Peer 的目标地址选择及来源地址检查语义；Shadowrocket 的 Global Routing 和 Config 规则则决定应用请求使用什么策略。不能将一份系统级 WireGuard 配置的路由效果，直接等同于 Shadowrocket 当前的规则分流效果。

• 0.0.0.0/0 表示覆盖全部 IPv4 地址范围，::/0 表示覆盖全部 IPv6 地址范围；这是地址范围表达，不是 DNS 服务器地址。
• Global Routing → Direct 会使用直接连接姿态，不适合作为验证所选 WireGuard 条目是否承载请求的测试条件。
• Global Routing → Config 按当前配置处理请求。若请求命中 DIRECT，即使选中了 WireGuard 条目，也不能据此认定它传输了该请求。
• DOMAIN-SUFFIX、IP-CIDR、GEOIP 与 FINAL 是规则匹配关键字，不能填写到 Private Key、Public Key 或 Address 中。

MTU 的取值思路与测试方法

MTU 表示接口可承载的 IP 数据包大小上限。WireGuard 封装还需要外层 IP、UDP 与协议开销，所以隧道内部能够使用的大小通常低于外层链路的 MTU。路径中还可能存在其他封装，不能仅凭 Wi-Fi 信号强弱或宽带带宽推算 MTU。

1420 是常见的 WireGuard MTU 起点，1280 可作为缩小数据包的诊断参考，但都不是对所有网络成立的固定答案。已有配置明确给值时先照填；未提供时先保留默认。仅当出现“小请求成功、大页面或较大传输停住”等现象，再把 MTU 纳入排查。

1. 记录原始 MTU、当前网络、Global Routing 姿态和测试目标，保留能够恢复的基线。
2. 先确认相同条目在当前网络上能完成实际请求。完全没有通信时，应优先查密钥、Endpoint 和 UDP 可达性，而不是连续试多个 MTU。
3. 若默认或 1420 下稳定复现较大传输卡住，可暂试 1380；仍异常再以 1280 作诊断对照。每次只改 MTU，重新建立连接并重复同一操作。
4. 在 Wi-Fi 与蜂窝网络分别记录结果。某个值只在其中一种网络有效，通常说明路径条件不同，不能据此把另一种网络判为配置错误。

这些数值是测试顺序示例，不是本站实测结论。降低 MTU 后恢复访问，只能提示问题可能与路径 MTU、分片或相关报文处理有关；还需重复验证。若降低后没有变化，应恢复原值，转查其他层，不要把越小越稳当作长期设置原则。

DNS 要同时检查解析器和到达路径

WireGuard 本身不定义一个统一的 DNS 配置分发协议。常见配置文件中的 DNS 是供客户端或配置工具使用的信息，不是由 WireGuard 握手自动协商出的解析器。Shadowrocket 中实际采用什么解析设置，还要结合当前 Config 的 DNS 配置与应用设置判断。

Endpoint 使用域名时，建立隧道前必须先能解析这个域名。如果把解析完全依赖于隧道内才能到达的 DNS，可能形成“先有隧道才能解析、先解析才能建隧道”的依赖问题。另一方面，服务商提供的内网 DNS 即使地址格式正确，也未必能通过 Direct 到达。

• 仅 Endpoint 域名失败：先核对拼写，并确认当前网络能解析该名称；不要通过改 Public Key 处理域名解析错误。
• 隧道已可传输但普通域名失败：检查当前配置中使用的 DNS 地址及其访问路径，确认没有把内网解析器发往不可达的直接连接。
• 只有部分网站异常：同时检查 IPv4、IPv6 可达性与规则命中结果。存在 AAAA 记录，不等于当前隧道一定具备对应的 IPv6 出口。
• 更换解析器后测试：重新建立连接并重试同一目标，留意应用或系统缓存；不要用一次旧页面成功就认定设置已经生效。

常见填写问题与排查顺序

连接开关保持开启，只能说明系统 VPN 会话处于相应状态，不足以单独证明 WireGuard 已成功交换数据。排查时按“资料完整 → Endpoint 与 UDP → 密钥对应 → 地址与策略 → DNS → MTU”的顺序推进，比随机切换所有参数更容易得到明确结论。