2026-09-28 · 协议科普 · 约 10 分钟

Shadowrocket WireGuard 配置参数详解:私钥、Peer、AllowedIPs 与 MTU

逐项解释在 Shadowrocket 中添加 WireGuard 时各字段的含义,说明如何把服务商提供的配置对应填入,以及 MTU 与 DNS 填错时的常见表现。

本文速览

本文适合已经持有自己服务商提供的 WireGuard 配置、需要在 Shadowrocket（小火箭）中核对参数的用户。先区分本机身份与远端 Peer，再核对地址、密钥、AllowedIPs、DNS 和 MTU，最后用一次只改一项的方式定位连接问题。文中的地址与端口仅用于说明字段关系，不是可用连接资料。

1. 先分清 Interface 与 Peer 的角色

WireGuard 配置通常用 [Interface] 描述本机隧道接口，用 [Peer] 描述允许通信的远端。Shadowrocket 的添加页面可能把这些内容拆成独立字段，因此不能只按文件中出现的先后顺序填入，更不能把两个位置的密钥互换。

本机 PrivateKey 决定本机身份，远端需要登记与它对应的本机公钥。本机配置里的 Peer PublicKey 则用于验证远端身份。两者都常表现为 Base64 文本，仅凭长度或结尾符号不能判断应该填在哪一栏。

参数归属：本机接口与远端 Peer

Interface：本机身份
  • PrivateKey：本机私钥，必须保密。
  • Address：服务端分配给本机的隧道地址。
  • MTU：隧道接口的报文大小限制。
  • DNS：配置文件可能附带的解析设置，不属于 WireGuard 握手参数。
Peer：远端身份与路径
  • PublicKey：远端公钥，不是本机公钥。
  • PresharedKey：可选的预共享密钥，双方须一致。
  • Endpoint：远端公网地址及 UDP 端口。
  • AllowedIPs：与这个 Peer 关联的目标和来源地址范围。

先确认每项参数属于哪一端，再进行字段映射；修改本机私钥后，远端登记的本机公钥也必须同步调整。

2. 按字段核对地址、密钥与端口

Address 是隧道内部地址，不是远端服务器地址。例如 10.66.0.2/32 表示一个 IPv4 主机地址；其中 /32 是前缀长度，不能随意替换成 /24。如果页面将地址和前缀拆开，应按字段分别填写，而不是机械粘贴完整一行。

来源字段填写含义常见误填与核对方式
PrivateKey本机 WireGuard 私钥。不要填成远端 PublicKey；复制时检查换行、空格及缺失字符。
Address分配给本机的 IPv4 或 IPv6 隧道地址。不要填 Endpoint；保留原始前缀长度，双栈参数分别核对。
Peer PublicKey远端 Peer 的公钥。不要用本机公钥替代；必须与实际连接的远端匹配。
PresharedKey双方共同持有的可选密钥。原配置未提供时不要自创；一端有值、另一端无值会导致通信失败。
Endpoint远端地址与 UDP 端口。192.0.2.10:51820 中地址与端口应对应各自字段；此地址仅作说明。
PersistentKeepalive空闲时维持 NAT 映射的发送间隔，单位为秒。25 是常见示例，不是通用必填值，也不是连接超时时间。

WireGuard 使用 UDP。端口 51820 是常见配置示例，不是协议强制端口，也不表示任何填入该端口的地址都可使用。Endpoint 为 IPv6 时，配置文件中的带端口写法通常是 [2001:db8::10]:51820；如果界面将地址与端口分开，方括号和冒号的处理应遵循该字段的输入格式。

UDP
WireGuard 外层传输；TCP 端口可达不等于隧道可用
51820
常见 Endpoint 端口示例，实际以已有配置为准
25 秒
PersistentKeepalive 示例间隔，不是默认要求

3. 在 Home 添加并建立可重复的测试

操作前保存一份原始配置，记录当前使用的 Wi-Fi 或蜂窝网络，以及原有 Global Routing 选择。若配置来自用户已有订阅，先确认订阅内容确实包含 WireGuard 条目；更新可能重建条目，手动修改前应记录差异，避免把后续覆盖误认为设置未保存。

  1. 准备原始资料

    确认资料包含本机 PrivateKey、隧道 Address、远端 PublicKey 和 Endpoint。若资料只给了公钥或只有端口，先向原配置提供方核实，不能据此推导出完整连接参数。

  2. 选择协议

    进入 Home → + → Type → WireGuard。按编辑页实际字段填写远端地址、端口、本机密钥和隧道地址；不同界面布局可能拆分地址与前缀，不要把整个配置文件粘贴到单个密钥字段。

  3. 核对远端

    填写 Peer PublicKey，并核对已有资料中的 PresharedKey、AllowedIPs 和保活间隔。若当前页面没有对应字段，不要改填到名称相似的其他位置，应先核实该导入形式支持的参数。

  4. 保存并连接

    保存后回到 Home，选择刚添加的条目，再打开连接开关。首次连接时按系统提示允许 VPN 配置。系统显示 VPN 状态只说明隧道接口已启动，不能单独证明远端已成功响应。

  5. 记录测试结果

    在 Home → Global Routing → Proxy 下做一次短时对照，确认所选条目可承载目标请求；记录测试目标、错误现象和网络类型。完成后恢复原来的 Config 或其他日常姿态，避免把测试设置长期保留。

测试期间检查 Settings → On Demand 是否存在自动连接条件。On Demand 负责系统连接触发，不负责决定某个域名采用哪条规则；若它在切换网络后重新触发连接，应在记录中说明，避免将自动重连当作 WireGuard 参数修改的效果。

4. AllowedIPs 与 Global Routing 不是同一层规则

WireGuard 的 AllowedIPs 将 IP 网段与 Peer 关联：发送时据此选择可承载目标地址的 Peer，接收时限制这个 Peer 可使用的内部来源地址。它不接受域名，也不等同于 Shadowrocket 的 DOMAIN-SUFFIX、GEOIP、IP-CIDR 或 FINAL。

在 Shadowrocket 中，还要核对请求最终是否被选到 WireGuard 条目。Config 下按当前配置规则和策略选择处理请求，不能假定未命中规则的流量一定直连，最终结果取决于兜底设置。即使 AllowedIPs 覆盖很广，命中 DIRECT 的请求也不会因此自动转入所选 WireGuard 路径。

Config：按配置判定

推荐

依照当前配置中的规则与策略处理请求。检查目标是否命中预期规则，以及对应策略是否实际选择了 WireGuard 条目；同时核对 FINAL 的兜底方向。

适合：已确认隧道可用后，恢复日常规则分流。

Proxy：代理方向对照

用于短时核对所选代理路径，减少规则选择对排查的干扰。该姿态不会修复错误密钥、不可达的 UDP Endpoint 或远端缺失的路由。

适合：区分“选路没有进入该条目”与“该条目自身不可用”。

Direct：直连基线

将直连方向作为网络基线，观察相同目标在不经代理路径时的表现。Direct 下网页正常，不能证明 WireGuard 参数正确。

适合：核对本地网络是否本来就无法访问测试目标。

5. DNS 与 MTU：连接后仍异常时的核对项

DNS 决定名称如何解析

WireGuard 握手不依赖配置文件里的 DNS 字段；但 Endpoint 若写成域名，建立外层连接前仍需要先解析它。隧道建立后，网页域名也需要解析。因此“Endpoint 解析失败”和“业务域名解析失败”应分别记录，不能统称为密钥错误。

配置文件里的 DNS 通常属于客户端配置工具扩展，不是 WireGuard 协议本身交换的参数。导入后应到 Config 检查当前启用配置中的 DNS 设置，确认 DNS 请求实际采用的路径，不要假定原文件中的 DNS 一定覆盖了 Shadowrocket 的现有设置。

MTU 决定隧道内报文的大小上限

MTU 过大时，常见现象是连接似乎建立、少量文本能返回，但大页面、上传或较大的数据传输停滞。这只是线索，不是确定诊断；远端拥塞、UDP 丢包或服务端限制也能产生相似表现。MTU 过小则可能增加报文数量与封装开销，并非越小越稳定。

  1. 先保留配置提供方给出的 MTU，记录同一网络、同一目标和同一操作的表现。
  2. 如果原值为 1420，可将 1380 作为一次较小值的对照；这些数字是测试示例，不是所有网络的最佳值。
  3. 保存后断开并重新连接，再重复原测试。此轮不要同时更换 DNS、Endpoint 或密钥。
  4. 若没有改善，恢复原值，继续检查路径丢包与远端状态；IPv6 隧道也不应随意降到低于其最小链路 MTU 1280 的值。

6. 按现象排查，不用单次延迟代替验证

延迟测试反映的是特定测试方法下的结果，不保证业务数据已经走通。排查应依次覆盖外层 UDP 可达性、Peer 身份匹配、隧道地址与远端路由、DNS 以及应用请求。若能查看远端握手和收发计数，应与一次明确发起的请求对应观察，而不是只看界面是否出现连接图标。

VPN 图标出来了，为什么还是打不开网页？

回到 Home 确认选中的是目标 WireGuard 条目，再短时切换 Global Routing → Proxy 对照。若仍失败，先核对 Endpoint、UDP 端口与双方公钥关系；只有接口启动、没有远端响应时，优先改 DNS 或 MTU 通常无法解决问题。

换成蜂窝网络就不通，要改 PrivateKey 吗？

先不要更换身份。使用原参数分别记录 Wi-Fi 和蜂窝网络结果，核对 Endpoint 在两种网络下的解析和 UDP 可达性。若仅空闲一段时间后失效，再与原配置提供方确认是否需要 PersistentKeepalive；更换私钥会要求远端重新登记公钥。

小页面能打开，上传文件却停住怎么办？

保留相同网络和测试目标，对 MTU 做单项降低测试，并重新连接后复测。若结果没有变化，恢复原 MTU；继续检查丢包、远端出口和目标服务限制，不要把所有大流量失败都归为 MTU 问题。

同一份配置能同时放在 iPhone 和 iPad 吗？

是否允许取决于远端分配方式。两台设备同时使用相同私钥和隧道地址，可能导致远端观察到的 Endpoint 来回变化。需要并发使用时，应向原配置提供方确认独立 Peer、独立密钥及地址安排，而不是只复制同一个条目。

更新订阅后，手动改过的 MTU 又变回去了？

先对照更新前后的字段记录，确认条目是否由订阅重建。由订阅管理的参数应以已有订阅的维护方式为准；如需单独测试，应保留原条目并记录本地副本的用途，避免把副本与自动更新条目混用。

7. 保存排查记录与使用边界

一次有效的排查记录，应能让同一用户在相同条件下复现问题，同时不暴露连接凭据。保留可用的原始参数，比连续尝试多个不相关改动更有价值。完成排查后恢复日常 Global Routing 选择，并核对 On Demand 是否仍符合预期。

App Store 正版核验 →