· 协议科普 · 约 12 分钟

Shadowrocket WireGuard 配置：PrivateKey、PublicKey、Endpoint 与 MTU 逐项说明

讲解在 Shadowrocket 中添加 WireGuard 节点时各字段的含义，以及 Address、DNS、MTU 的常见取值，并说明服务商给的配置怎么对应到客户端。

本文速览

本文面向已从自己的服务商处取得 WireGuard 参数的用户，说明如何区分本机与远端的密钥、把配置文件字段对应到 Shadowrocket，以及按顺序排查 Endpoint、DNS 和 MTU。先保留原配置，再核对身份与地址，最后调整影响传输的参数；不应通过反复更换密钥或照抄示例地址尝试连接。

1. WireGuard 配置中的本机与远端

在 Shadowrocket（小火箭）中，WireGuard 是连接协议，不是订阅格式，也不是分流规则。本文以服务商提供的客户端配置为参照：[Interface] 描述本机隧道接口，[Peer] 描述远端对等方。先确认文件是给客户端使用的，再填写字段；不能把服务端配置直接当作客户端配置使用。

订阅链接或独立配置均应从你的服务商处获取。如果已有订阅导入后生成了完整的 WireGuard 条目，先核对条目即可，不必再手动创建一个同名条目。订阅更新可能重新写入参数；需要测试修改时，保留原条目，并把测试副本与订阅管理的条目区分开。

2 个区段
客户端配置通常区分 [Interface] 与 [Peer]
UDP
WireGuard 的外层传输使用 UDP
51820
常见端口示例，不是必须填写的固定值

配置填写正确与请求实际经过该连接是两个问题。Home 中选择的条目、Global Routing 的姿态，以及 Config 中命中的规则，都会影响请求路径。应先核对连接参数，再检查流量是否被分配到该条目，避免把规则直连误判成 WireGuard 失效。

2. PrivateKey、PublicKey 与 PresharedKey 的对应关系

PrivateKey 是本机身份的私密部分；客户端配置中 [Peer] 的 PublicKey 则用于识别远端。两者属于不同的身份，不能相互替换，也不能把本机由 PrivateKey 派生出的 PublicKey 填到远端 PublicKey 位置。服务端需要登记与本机 PrivateKey 对应的公钥，双方配置才可能匹配。

本机接口：Interface

PrivateKey
客户端私钥，保留完整内容，不公开分享。
Address
分配给客户端的隧道地址，不是远端服务器地址。
DNS
配置提供的解析器地址，需要结合实际解析路径核对。
MTU
隧道接口的报文大小参数，不是带宽或速度上限。

这些字段描述本机侧配置，不应从服务端接口区段照搬。

远端对等方：Peer

PublicKey
远端公钥，必须与所连接的服务端身份一致。
PresharedKey
可选的额外共享密钥，只有服务商提供并启用时才填写。
Endpoint
远端主机与 UDP 端口，客户端向此处发起通信。
AllowedIPs
WireGuard 的地址选择与校验范围，不等同于域名分流规则。

完整 WireGuard 配置中的字段不一定在编辑页以同名项目逐一呈现。

WireGuard 密钥采用 Base64 编码的 32 字节值，常见文本长度为 44 个字符，末尾可能包含 =。长度相符只能作为格式检查，不能证明密钥与服务端匹配。复制时应去掉首尾空白，避免混入换行、引号或说明文字，也不要删除末尾的填充字符。

3. Endpoint 与 Address：服务器入口不等于隧道地址

Endpoint 包含远端主机和端口。例如 192.0.2.1:51820 中，主机为 192.0.2.1，端口为 51820。如果 Shadowrocket 编辑页把地址和 Port 分成两项，应分别填写；不要把带端口的整段内容放进只接受主机名的地址栏。IPv6 Endpoint 在组合表达时需要方括号，例如 [2001:db8::1]:51820。

Address 是隧道内部使用的本机地址，常以带前缀长度的形式提供，例如 10.66.0.2/32。服务商若同时提供 IPv4 与 IPv6，应按其分配结果填写。不要把 Endpoint 的公网地址放进 Address，也不要从其他设备复制同一个隧道身份并同时使用，以免产生身份或地址冲突。

字段示意值核对重点
Endpoint192.0.2.1:51820远端地址与端口成对核对；实际端口可能不是 51820。
Address10.66.0.2/32使用服务商分配的本机隧道地址，保留前缀信息。
DNS10.66.0.1若是隧道内部解析器，必须有可用的到达路径。
AllowedIPs0.0.0.0/0, ::/0在 WireGuard 语义中覆盖全部 IPv4 与 IPv6，不代表应用层规则一定全部走此条目。

表中的地址只用于解释字段，不能作为可用配置。尤其是 192.0.2.1 与 2001:db8::1，属于文档示例地址。端口开放、远端支持 UDP、密钥匹配，以及本地网络允许对应通信，都是实际连接所需的条件。

4. 在 Home 添加 WireGuard 条目的核对步骤

手动添加适用于已经拿到独立参数的情况。以下路径以英文界面词为参照，字段排列可能随设备布局变化；若服务商提供的项目在编辑页没有对应输入项，不要把内容挤进其他字段，应先确认该配置的导入方式与支持范围。

  1. 保留原配置

    保存服务商原始参数，并记录 Home 当前选中的条目与 Global Routing 姿态。测试期间每次只改变一项，便于恢复。

  2. 选择协议

    进入 Home → 右上角「+」→ Type → WireGuard。先确认 Type，再填写地址、Port 与密钥，避免沿用其他协议表单的含义。

  3. 对应字段

    将 Endpoint 拆成远端主机与 Port；PrivateKey 对应本机私钥，PublicKey 对应远端公钥。Address、DNS、MTU 按原配置及编辑页支持的项目填写。

  4. 保存并选中

    保存后回到 Home，选中刚添加的条目，再开启连接。首次配置 VPN 时按系统提示授权；系统显示 VPN 已连接，不等于远端握手与业务请求都已成功。

  5. 固定测试条件

    先保持同一个网络与同一个测试请求。若 Settings → On Demand 已启用，记录其条件，避免自动连接行为干扰手动测试；完成后恢复原设置。

不要因为 Home 中一次延迟测试显示数值就认定所有业务均可用。测试结果取决于测试方式、目标与请求路径；应继续检查域名解析、实际页面加载和较大内容的传输。反过来，某种延迟测试失败也不能单独证明 PrivateKey 错误。

5. DNS 与 AllowedIPs：区分解析路径和请求路径

DNS 不是 WireGuard 加密握手本身的字段，而是常见配置工具用于安排解析器的设置。Shadowrocket 的实际解析行为还与当前 Config 和相关 DNS 设置有关。因此，服务商配置里的 DNS 地址与应用中已有的解析设置，需要一起核对，不能只看其中一个位置。

如果 Endpoint 使用主机名，建立隧道前就需要解析这个主机名。若唯一可用的解析器又只能通过尚未建立的隧道到达，就可能形成依赖循环。此时应向服务商确认可用的入口解析方案，而不是随意把 DNS 改成一个无法确认可达的地址。

6. MTU 如何选择：原值优先，单项对照

MTU 表示接口可承载的最大 IP 报文大小，单位是字节。WireGuard 会在原始报文外增加传输封装，因此隧道 MTU 通常小于底层链路 MTU。常见配置会出现 1420，但这不是所有网络的统一答案；底层链路、额外封装与路径限制都可能改变合适的值。

典型排查线索是：小请求能够完成，但较大响应持续停顿，或者切换网络后同一配置出现大流量异常。这类现象可能与路径 MTU 探测或分片有关，也可能来自丢包与拥塞。应先确认密钥、Endpoint 和 DNS，再通过只改 MTU 的对照测试缩小范围。

沿用服务商值

推荐

服务商明确提供 MTU 时，先保留原值作为基线。例如原配置为 1420，就先验证该值下的握手、解析和实际传输，不同时更换 DNS 或 Endpoint。

适合：首次导入、配置迁移、建立可复现的测试基线。

保留默认处理

原配置未提供 MTU，且编辑页允许不指定时，可先保留默认处理。不要仅因看到其他配置使用 1420 就强行填写；默认行为不应被理解为固定的单一数值。

适合：服务商没有特别要求，当前传输也没有明显异常。

1280 对照测试

当大报文传输异常且其他参数已核对时，可在配置允许的情况下临时测试 1280。它也是 IPv6 最小链路 MTU 的参考值，但不保证解决所有路径问题；测试后记录差异并决定是否恢复。

适合：小请求正常、大内容停顿，需要验证报文大小影响的情况。

较小的 MTU 不等于更快。它可能减少某些路径上的大报文问题，也会增加同等数据量所需的报文数量与封装开销。有效结论应来自同一网络、同一条目、同一目标下的前后对照，而不是只比较延迟测试数字。

7. 连接失败时的分层检查顺序

先区分“系统 VPN 已启动”“远端通信可用”和“目标请求可完成”这三种状态。WireGuard 在没有业务流量时可以保持安静，不能仅凭短时间没有数据就判断断线。反复关闭和开启连接也不会自动修正错误的 PublicKey 或端口。

观察到的现象优先核对下一步
所有请求均失败Endpoint、Port、UDP 可达性、双方密钥对应关系确认服务商登记的客户端公钥与当前 PrivateKey 对应。
域名请求失败Endpoint 的预先解析、业务 DNS、当前 Config区分入口域名解析失败与隧道内 DNS 不可达。
小请求正常，大内容停顿丢包、路径 MTU、网络切换后的差异固定其余条件，只调整 MTU 做对照。
订阅更新后参数恢复条目是否由订阅管理对照原始配置，在测试副本验证修改，不反复覆盖来源条目。
只有部分目标未经过隧道Global Routing、当前 Config、命中策略检查分流结果，而不是立即重建 WireGuard 身份。

若设备频繁在 Wi-Fi 与蜂窝网络间切换，应分别记录两种网络的结果。可选的 PersistentKeepalive 用于定期发送保活，常见示例为 25 秒，但仅应在服务商要求或确有 NAT 映射保持需求、且当前配置方式支持时设置。它不能修复错误密钥，也不是速度调节器。

向服务商反馈时，记录网络类型、Endpoint 端口、发生问题的请求类型、是否仅大内容失败，以及修改 MTU 前后的差异。分享配置截图或日志前，遮盖 PrivateKey、PresharedKey、订阅令牌与其他身份信息。保留这些可复现的条件，比只描述“连不上”更有助于定位问题。

App Store 正版下载核对开发者与应用 ID