2026-10-03 · 协议说明 · 约 10 分钟

Shadowrocket WireGuard 配置说明:私钥、公钥、Endpoint 与 MTU 各参数含义

逐项解释在 Shadowrocket 里添加 WireGuard 时要填的参数,对应服务商给出的配置字段,并说明常见填写错误。

本文速览

本文面向已经持有自己服务商 WireGuard 配置的用户，先区分本地 Interface 与远端 Peer，再说明密钥、隧道地址、Endpoint、AllowedIPs、DNS 和 MTU 的对应关系，最后给出 Shadowrocket 中的添加步骤与分层排查顺序。重点是把现有参数填对，而不是生成一套未经服务端登记的新参数。

先区分 Interface 与 Peer

WireGuard 是基于 UDP 的加密隧道协议。它不使用传统的用户名与密码登录，而是通过密钥识别通信双方。Shadowrocket（小火箭）中选用 WireGuard 时，需要的是相互配套的客户端参数与服务端参数；只有一个服务器地址，不能完成配置。

常见 WireGuard 配置文件用 [Interface] 表示本地隧道接口，用 [Peer] 表示对端。这里的“本地”是当前设备，“对端”通常是用户已有服务的服务器。客户端配置里的 PrivateKey 属于当前设备，而同一文件中 [Peer] 下的 PublicKey 属于服务器，两者不是同一对密钥。

UDP
WireGuard 外层传输，不是 TCP 连接
32 字节
PrivateKey 与 PublicKey 解码后的长度
51820
常见示例端口，实际必须服从服务配置

原生 WireGuard 配置文件与 Shadowrocket 配置文件不是同一种格式。前者中的 [Interface]、[Peer] 不能直接当作 Shadowrocket 的 [Rule] 规则使用。手动添加时，应把每个值对应到 WireGuard 编辑页的相应字段；某个客户端没有展示原生文件的全部选项，也不代表可以把剩余内容随意填入其他字段。

密钥参数：PrivateKey、PublicKey 与 PresharedKey

PrivateKey 是本地私钥，必须保密。它通常是 Base64 编码文本，32 字节的密钥编码后一般为 44 个字符，末尾的 = 也是内容的一部分。复制时不要带入字段名、引号、空格或换行，也不要把它当成网址解码。字符长度正确只说明格式可能正确，并不证明它与服务器上的登记记录匹配。

PublicKey 是对端公钥，用来确认通信对象。客户端自己的公钥由客户端私钥推导，并登记在服务器对应 Peer 中；客户端编辑页里需要的对端公钥则来自服务器。把客户端自己的公钥填到对端位置，或者把服务器公钥误填成私钥，都会使握手无法正常建立。

本地 Interface 参数

PrivateKey
当前设备的私钥，不是服务器私钥。
Address
分配给本地隧道接口的地址，保留原前缀长度。
DNS
配置提供的解析器地址，需要结合客户端 DNS 设置确认生效方式。
MTU
隧道接口的最大传输单元，单位为字节。

这些值描述本地接口，不应与服务器的公网地址混填。

远端 Peer 参数

PublicKey
服务器公钥，必须与目标服务器匹配。
PresharedKey
可选的预共享密钥；启用时双方必须完全一致。
Endpoint
服务器主机地址及 UDP 端口。
AllowedIPs
该 Peer 对应的隧道目标地址范围。

这些值描述对端。不要把服务端配置文件原样当作客户端配置填写。

PresharedKey 是附加的对称密钥，不替代公私钥。如果已有配置没有提供它，应保持未设置状态；若服务端启用了它，客户端遗漏或填错也会导致握手失败。不要为“填满所有字段”自行生成一个值，更不要把 PrivateKey 再复制一遍作为 PresharedKey。

Endpoint 与 Address：公网入口不等于隧道地址

Endpoint 表示建立隧道时先要访问的服务器入口。例如 192.0.2.10:51820 中，192.0.2.10 是文档示例地址，51820 是 UDP 端口。如果 Shadowrocket 的编辑页把地址与端口分开显示，就分别填写，不要把整串带端口的内容重复填入地址栏。地址前不加 https://，末尾也不添加网页路径。

以域名作为 Endpoint 时，域名需要先能解析，再通过当前网络访问对应 UDP 端口。网页可以打开或 TCP 端口测试成功，都不能证明这个 UDP 入口可用。IPv6 的合并写法需要方括号，例如 [2001:db8::10]:51820；若编辑页提供独立地址字段，按该字段的格式填写，不把合并形式的括号机械照搬。

字段文档示例不能混用的值
Endpoint192.0.2.10:51820不能填成本地隧道 Address。
Address10.66.0.2/32不能填服务器公网入口或家中 Wi-Fi 地址。
AllowedIPs0.0.0.0/0, ::/0不能把它当成服务器地址列表。
DNS10.66.0.1只有现有配置明确提供且隧道可达时才使用。

Address 是服务器分配给客户端的隧道内地址，可能同时包含 IPv4 与 IPv6。保留服务商提供的前缀长度，例如 /32 或 /128，不要因为看到家用网络常见的 /24 就自行替换。地址冲突、未登记或与服务器允许范围不符，都可能出现握手建立后数据仍不通的情况。

AllowedIPs、DNS 与 MTU 分别控制什么

在 WireGuard 中，AllowedIPs 与 Peer 的隧道地址范围关联，参与出站 Peer 选择和入站来源校验。0.0.0.0/0 覆盖全部 IPv4 目标，::/0 覆盖全部 IPv6 目标；但这不等于服务器一定提供双栈转发，也不等于 Shadowrocket 的每一个请求都会进入该 WireGuard 连接。客户端自身的路由姿态与配置规则仍决定请求使用哪个策略。

DNS 解决的是域名到地址的解析，隧道负责的是数据传输。原生配置中的 DNS 常由配置管理程序应用，不属于 WireGuard 握手本身。手动转填到 Shadowrocket 时，还要核对当前配置中的 DNS 设置，不能只看原文件里存在一行 DNS 就认定应用中的解析路径已经一致。

MTU 是隧道接口一次承载的 IP 包大小上限。WireGuard 还需要外层 IP、UDP 和加密封装空间；在不含其他额外封装的计算中，IPv4 外层通常需要约 60 字节，IPv6 外层约 80 字节。因此，若底层路径 MTU 为 1500，1420 是常见参考值，但不能把它视为所有网络或 Shadowrocket 的固定默认值。

优先保留已有配置明确给出的 MTU。若出现小请求能返回、大网页或上传持续卡住的现象，可以记录原值后做单变量测试，例如从 1420 降到 1380，再重试相同请求。这只是排查路径 MTU 问题的方法，不是对具体网络的实测结论；降低后无变化，应恢复原值并继续检查其他层次。

在 Shadowrocket 中添加与验证

以下步骤以 Home 中手动添加 WireGuard 为主。不同平台的编辑页可能拆分或合并字段，应按含义对应，而不是按表单行数照搬。开始前保存一份原始配置，先完成最小可用验证，再调整路由、DNS 或 MTU；一次改动过多，会失去判断原因的依据。

  1. 核对原配置

    把 [Interface] 与 [Peer] 分开阅读，确认有本地 PrivateKey、Address、服务器 PublicKey 和 Endpoint。检查 PresharedKey 是否存在，不自行补造缺失参数。

  2. 选择协议

    进入 Home → 右上角「+」→ Type → WireGuard。确认当前编辑的是 WireGuard 连接，不能把这些参数填进其他协议类型。

  3. 填写参数

    按本地接口与远端 Peer 的对应关系填写。Endpoint 若分为地址和端口两栏，就分别输入；密钥完整复制，Address 保留原前缀长度。对于未显示的可选项，不借用其他字段代填。

  4. 保存并选中

    保存后回到 Home，选中刚添加的连接。记录 Global Routing 当前姿态；如需暂时排除配置规则影响，可使用 Proxy 做单次验证，测试结束恢复原来的日常设置。

  5. 验证与记录

    启动连接，按系统提示确认 VPN 配置。分别测试域名访问、小请求与较大内容加载；记录网络类型、错误现象及改动项。若 Settings → On Demand 已设置自动连接条件，排查期间一并核对，避免它干扰手动切换。

订阅中的 WireGuard 条目与手动添加条目也应区分。更新用户已有订阅后，远端管理的条目可能随订阅内容变化；本地临时修改不能当成长期配置来源。若更新后失效，先比较 Endpoint、PublicKey、Address 是否已经变更，再决定是否需要重新导入自己的配置。

Global Routing 姿态与故障定位

在 Shadowrocket 中，协议参数正确与业务请求实际使用这条连接是两件事。WireGuard 定义隧道如何建立，Global Routing 以及 Config 中的规则决定请求走哪条路径。不要把“某个网站打开了”直接当作 WireGuard 已经连通的证据，因为该请求可能使用 DIRECT。

Config

推荐

按当前启用配置的规则选择策略。规则可以把不同请求交给 DIRECT、代理策略或 REJECT；未命中请求由 FINAL 指定的策略处理，并不固定等于直连。

适合：参数验证完成后，按已有规则进行日常分流。

Proxy

让代理路径使用当前选中的连接，可用于暂时排除 Config 中业务分流规则的影响。仍需确认选中的是目标 WireGuard 条目，且当前网络能访问其 UDP Endpoint。

适合：短时确认问题来自 WireGuard 连接还是配置规则。

Direct

使用直连路径，适合作为当前网络的基线对照。此姿态下访问成功，不代表 WireGuard 的密钥、服务器入口或隧道转发已经正常。

适合：对照当前网络本身是否能访问同一目标。

若使用 Scene，应先确认当前场景实际采用的路由设置，不能把场景名称当作协议测试结果。在 Config 中，DOMAIN-SUFFIX、IP-CIDR、GEOIP 是不同的匹配条件，FINAL 是末尾兜底；排查时应观察请求命中了什么策略，而不是仅检查规则文件里是否出现 WireGuard 字样。

观察到的现象先检查下一步动作
没有成功握手迹象Endpoint、UDP 可达性、双方密钥、PresharedKey。若能查看服务端状态，核对握手记录；换一个已知可用网络做对照。
握手出现但请求超时Address、AllowedIPs、服务端转发与返回路由。确认分配的隧道地址仍有效，再检查业务请求是否进入目标策略。
只有域名访问失败DNS 响应、解析器可达性与实际 DNS 设置。区分解析超时、空响应和解析成功后的连接失败。
小请求正常，大内容卡住路径 MTU、封装开销与网络丢包。保留原值后单独降低 MTU 测试；无改善则恢复。
切网或闲置后失效NAT 映射、Endpoint 可达性与自动连接条件。重新建立连接作对照，再核对保活设置与 On Demand 条件。

排查时每次只改变一个变量，并保留能复现问题的操作。单次延迟测试结果不能替代握手、DNS 与实际业务验证；同样，连接开关处于开启状态，也不能证明服务器已经接受当前密钥。若需向已有服务商反馈，提供发生时间、网络类型、Endpoint 端口与错误现象即可，私钥和预共享密钥不应随反馈公开发送。

下载 Shadowrocket