2026-08-12 · 协议科普 · 约 10 分钟

Shadowrocket WireGuard 配置参数详解:Private Key、Peer、AllowedIPs 与 MTU

逐项解释在 Shadowrocket 中添加 WireGuard 节点时的字段含义:Private Key、Public Key、Endpoint、AllowedIPs、MTU 与 DNS,并列出常见填写错误。

本文速览

本文适合已经持有自己服务商提供的 WireGuard 参数、准备在 Shadowrocket（小火箭）中手动填写或核对配置的用户。先区分本地接口与 Peer，再检查密钥、地址、UDP 端点及 DNS；最后用路由姿态和分层测试判断故障位置。文中标准配置字段用于解释参数来源，不代表所有字段都能在客户端中按原名编辑。

一、先区分本地接口与 Peer

WireGuard 使用公钥识别通信对端，通过 UDP 传输加密数据。配置中的本地接口负责本机身份与隧道地址，Peer 表示远端通信对象。两部分的密钥不能混填：本机持有自己的 Private Key，连接远端时填写远端的 Public Key；远端则需要登记本机 Private Key 对应的 Public Key。

本文以用户已有合法可用的配置为前提。本站不提供、不销售、不推荐节点或订阅。WireGuard 参数不是一个地址加一个通用密码即可完成的组合，至少要核对密钥配对、本地隧道地址和远端端点。不要把 Shadowsocks、VMess、VLESS、Trojan 或 Hysteria2 的认证字段直接套入 WireGuard。

32 字节
WireGuard 密钥的原始长度；通常以 Base64 文本呈现
UDP
远端 Endpoint 的传输协议；没有统一必填端口
2 类
参数来源：本地 Interface 与远端 Peer

标准 WireGuard 配置中的 [Interface] 与 [Peer] 是理解参数的依据，不应直接当作 Shadowrocket 的 [Rule] 规则段。导入配置时也必须先确认文件格式受客户端支持，不能仅凭扩展名相同就互换。

二、Private Key、Public Key 与地址分别填什么

Private Key 是本机的秘密凭据，应从已有配置中完整复制，避免前后空格、换行或字符丢失。更换 Private Key 会改变本机身份；如果远端仍登记旧的 Public Key，即使 Endpoint 完全正确也无法完成有效通信。不要仅为尝试修复连接而随意重新生成密钥。

本地 Interface 参数

Private Key
本机私钥；必须与远端登记的本机 Public Key 对应。
Address
分配给本机的隧道地址，例如 10.7.0.2/32；不是远端服务器地址。
DNS
名称解析服务器地址；属于客户端集成设置，并非密钥握手参数。
MTU
隧道接口的包长上限，单位为字节；先保留提供方要求或默认值。

以上是源配置语义；在 Shadowrocket 中按实际字段与导入方式对应核对。

远端 Peer 参数

Public Key
远端的公钥，不是从本机 Private Key 推导出的公钥。
Endpoint
远端可达地址与 UDP 端口，例如 192.0.2.10:51820。
AllowedIPs
该 Peer 对应的隧道目标前缀及接收源地址校验范围。
Preshared Key
可选的附加共享密钥；若已配置，两端必须一致。

示例地址属于文档保留范围，不能用于实际连接；真实参数以用户已有配置为准。

Address 中的 /32 表示单个 IPv4 地址前缀，IPv6 单地址常见写法为 /128。这些地址由远端网络规划决定，不能因为与家中 Wi-Fi 地址不同就改成局域网地址。若源配置同时给出 IPv4 与 IPv6，应先确认远端和当前网络都具备对应能力。

三、在 Home 添加并核对 WireGuard

Shadowrocket 的 Home 用于选择连接项目，Config 管理规则配置，Settings 管理应用设置。先把 WireGuard 本身填对，再考虑规则分流。字段布局可能随应用界面调整，下列路径说明操作层级；源文件中的 AllowedIPs、DNS 等名称不一定在编辑页逐项出现，不要为缺少同名输入框而填入无关字段。

  1. 准备参数

    从自己的配置中确认本机 Private Key、隧道 Address、远端 Public Key、Endpoint 和可选 Preshared Key，保留原始副本用于对照。

  2. 选择类型

    进入 Home → 右上角「+」→ Type → WireGuard。先确定类型，再填写对应字段，避免把其他协议的编辑页当作 WireGuard 页面。

  3. 填写端点

    将 Endpoint 的主机与端口对应填入 Address 和 Port 等服务器字段。例如文档端点 192.0.2.10:51820 中，主机为 192.0.2.10，端口为 51820；这里的服务器 Address 与隧道 Address 不是同一概念。

  4. 核对密钥

    填写本机 Private Key 与远端 Public Key，并核对本地隧道地址。有 Preshared Key 时按原配置填写；没有时不要用密码或 Public Key 代替。

  5. 保存测试

    保存后回到 Home，选中该项目，再检查 Global Routing。首次测试只验证一个明确目标；诊断期间可在 Settings → On Demand 暂时关闭自动触发，防止手动断开后又自动连接。

51820 只是常见 WireGuard 监听端口，不是协议强制端口。若原配置写的是 443，就使用 443 对应的 UDP 端点；不能据此推断它支持 TCP 或 HTTPS。遇到网络阻断 UDP 时，更换一个数字不等于远端已经在新端口监听。

四、AllowedIPs 与 Global Routing 不是同一层规则

在标准 WireGuard 语义中，AllowedIPs 参与出站流量的 Peer 选择，并约束从该 Peer 接收的解密流量可使用哪些源地址。常见的 0.0.0.0/0 覆盖全部 IPv4 地址，::/0 覆盖全部 IPv6 地址；10.7.0.0/24 则只覆盖一个指定网段。它不是域名列表，也不是网站访问权限或付费额度。

Shadowrocket 还存在 Global Routing 与 Config 中的规则层。哪些应用请求交给所选连接处理，应结合当前路由姿态判断，不能看到源配置含有 0.0.0.0/0 就断言全部请求必定经由 WireGuard。Scene 用于场景化安排；基础排障时先使用明确的单一姿态，减少变量。

Config

推荐

依据当前配置中的规则选择策略。用于日常分流前，应先确认规则顺序以及 PROXY 实际使用的连接项目。

适合：WireGuard 已验证可用后，按域名或 IP 范围分流。

Proxy

将可由当前代理路径处理的请求交给所选连接，适合暂时排除 Config 规则的影响；不表示任何系统流量都必然被接管。

适合：短时间验证所选 WireGuard 连接是否能够传输业务数据。

Direct

请求直接连接，不用于验证 WireGuard 隧道是否可用。浏览器能打开页面，也不能据此判断隧道建立成功。

适合：建立本地网络基线，对比直连时是否也有相同故障。

下面是 Shadowrocket 的规则语法示意，不是 WireGuard 配置。DOMAIN-SUFFIX 匹配域名后缀，IP-CIDR 匹配 IP 网段，FINAL 处理此前未命中的请求。规则自上而下匹配，前面已经命中的请求不会继续交给 FINAL。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,DIRECT

这里的 example.com 与 192.0.2.0/24 仅用于文档说明。若改用 GEOIP，应理解它依赖 IP 地理数据库，不能代替对 Peer、AllowedIPs 或服务端回程路由的检查。更多规则语义可查看规则参考。

五、MTU 与 DNS：连接后仍打不开的两类原因

MTU 限制隧道接口可承载的 IP 包长。加密封装会增加外层开销，因此隧道 MTU 通常小于底层链路 MTU。1420 是常见参考值，但不是所有 Wi-Fi、蜂窝网络或嵌套隧道都适用的固定答案。应先使用已有配置指定值或默认值，只有出现相关症状时再做受控对照。

观察现象优先检查一次只改一项
小请求成功，较大响应反复停顿路径 MTU、丢包、远端转发若可编辑 MTU，可比较 1420 与 1380，记录后恢复或保留有效值
名称解析超时，但已知 IP 的诊断请求有响应DNS 地址与到 DNS 的路由核对原配置 DNS 是否只能通过隧道访问
仅部分 IPv6 目标失败IPv6 地址、路由与远端转发能力分别验证 IPv4 与 IPv6，不把添加 ::/0 当作修复方法
切换网络后不再收到数据UDP 可达性与 NAT 映射在新网络重新建立连接，再对比同一目标

上述是诊断现象与测试方法，不是本地实测结果。1380 也不是通用最优值；如果降低 MTU 后没有可重复改善，应恢复原值，继续检查其他层。不要同时更改 MTU、DNS、Endpoint 和路由姿态，否则无法判断是哪项产生影响。

DNS 负责把域名解析为地址，不参与 WireGuard 公钥握手。标准配置里的 DNS 通常由客户端工具解释，Shadowrocket 的实际解析行为还要结合当前 Config 的 DNS 设置。某个仅在隧道内部可达的 DNS 地址，不能在隧道尚未建立时承担所有前置解析任务，尤其当 Endpoint 本身也是域名时。

六、按“端点、握手、数据、规则”顺序排错

应用显示已连接或系统出现 VPN 标识，只能说明本地连接状态，不能独立证明远端已接受密钥或业务请求已到达目标。WireGuard 在没有流量时可以保持安静，因此要用明确请求触发测试；若用户有远端管理权限，可结合最近握手时间和收发计数核对。

  1. 端点层：确认主机名或 IP 无误，端口与远端监听一致，当前网络允许相应 UDP。域名解析成功不等于 UDP 端口可达。
  2. 握手层：确认本机 Private Key 对应的 Public Key 已在远端登记，远端 Public Key 正确，可选 Preshared Key 两端一致。只检查“长度看起来一样”不足以验证配对。
  3. 数据层：如果能握手但业务不通，核对隧道地址、AllowedIPs、远端转发、防火墙与回程路由。远端需要 NAT 还是明确回程路由，由其网络设计决定。
  4. 规则层：对比 Global Routing → Proxy 与 Config 下同一请求的结果。只有 Config 失败时，优先检查规则命中及策略引用，不必先更换密钥。
  5. 稳定性层：若空闲后失联，检查 NAT 映射与保活需求。标准配置中 PersistentKeepalive 的单位是秒，25 是常见示例，不是所有连接都必须启用；仅在已有配置要求且客户端支持对应设置时调整。

七、常见填写错误与保存前检查

手动配置最常见的错误不是协议选择不够多，而是字段角色混淆。保存前应逐项回看，尤其注意同样显示为 Address 的服务器地址与隧道地址。订阅中已有 WireGuard 项目时，手动修改还可能在下次更新后被替换，应保留独立记录，先确认数据由哪里维护。

完成检查后，先证明一个明确目标能够通过所选 WireGuard 项目传输，再恢复 Config 分流和日常自动连接设置。Shadowrocket 是 Apple 平台的闭源商业应用，以 iPhone、iPad 使用为主；价格、系统要求及其他 Apple 设备兼容性以 App Store 页面标注为准。客户端买断 ≠ 线路套餐，购买应用不会替代用户已有的连接服务与配置。

App Store 正版核验