Shadowrocket WireGuard 配置参数详解:私钥、对端公钥、地址、DNS 与 MTU 怎么填

一、填写前先确认配置来源与字段层级

Shadowrocket（小火箭）的 WireGuard 类型需要有效的对端配置，不能仅凭一个服务器地址建立连接。前提是用户已有自己的服务商与配置，或已管理相应的 WireGuard 对端。本站不提供、不销售、不推荐节点或订阅。若现有资料只有普通订阅链接，先确认其中是否确实包含 WireGuard 类型记录，不要把订阅 URL 填进服务器地址。

常见 WireGuard 配置把内容分成 [Interface] 与 [Peer] 两部分。前者描述本机身份和隧道接口，后者描述远端身份及连接目标。Shadowrocket 将这些信息映射到服务器编辑表单；字段排列与显示名称以当前界面为准，下面保留配置原始键名，便于逐项核对。

收到配置后，先保留一份安全备份，再做录入。不要在公开求助内容中附上 Private Key、Preshared Key 或完整订阅链接；这类信息可能直接关联连接权限。只需核对格式时，可说明字段长度、是否存在空格以及所在配置段，无需披露具体密钥。

二、Private Key 与 Public Key：本机私钥、对端公钥不能互换

[Interface] 中的 PrivateKey 是客户端私钥，必须与对端已登记的客户端公钥相配。[Peer] 中的 PublicKey 则是服务器的公钥，用于识别远端。两者看起来都像一串 Base64 文本，但用途不同，不能根据外观判断，也不能把客户端自己的公钥填进对端 Public Key。

标准 WireGuard 密钥编码为 Base64 后通常是 44 个字符，末尾可见 =。长度看起来正确只说明格式可能成立，不代表密钥对应关系正确。粘贴时去掉前后的空格、引号与换行，但保留密钥本身的 +、/、= 等字符。

• 若重新生成客户端私钥，对端必须同步登记由它导出的新客户端公钥；只改本机通常不能恢复连接。
• 不要从服务器端的 [Interface] 复制 PrivateKey 到客户端。需要的是专门分配给该客户端的配置。
• 原配置没有 PresharedKey 时保持未设置，不要拿 PrivateKey 或 PublicKey 补齐该项。
• 不要让两台设备同时使用同一份客户端身份；对端可能将回包发往最近一次活动的端点，表现为连接交替中断。

三、Address、Endpoint 与端口：区分隧道内外地址

Address 是隧道内部地址，Endpoint 是连接远端时使用的外部入口。两者不能交换。例如，配置给客户端分配 10.66.0.2/32，并给出 192.0.2.10:51820 作为 Endpoint：前者说明本机在隧道中的身份，后者说明加密 UDP 报文发往哪里。这里的 Endpoint 使用文档专用地址，仅用于解释格式，不能实际连接。

/32 是 IPv4 前缀长度，不是端口；IPv6 单地址配置中也可能出现 /128。如果界面要求单独填写 IPv4 地址，就不要把端口或整个 Endpoint 一并粘入。IPv6 地址只在原配置明确分配并且链路支持时填写，不能凭空补出一个地址。

AllowedIPs 在 WireGuard 中描述 Peer 可承载的目标范围及来源校验范围，不是客户端 Address 的另一种写法。即使原配置含有 0.0.0.0/0 和 ::/0，Shadowrocket 中具体连接是否选用该服务器，仍需结合 Global Routing 与 Config 规则判断，不能仅凭这两项断言所有应用都会使用它。

四、在 Home 添加 WireGuard 并做最小化验证

首次填写时先验证单个服务器，不同时修改路由、DNS 和 MTU。这样出现故障时，能明确是哪一步改变了结果。下面的入口用于添加 WireGuard 服务器；Config 用于配置文件与规则，不要将两种入口混为一谈。

1. 选择类型

   进入 Home → + → Type → WireGuard。返回编辑页后确认类型仍为 WireGuard，再继续填写。

2. 填写入口

   将 Endpoint 的主机与端口填入对应栏位。例如文档示例 192.0.2.10:51820 应拆为地址与端口；实际操作使用自己的有效参数。

3. 核对密钥

   填写客户端 Private Key 与对端 Public Key，再按原配置补充本机隧道地址；仅在明确提供时填写 Preshared Key。

4. 保存并选择

   保存服务器，回到 Home 选中该条目。首次连接按系统提示允许添加 VPN 配置；授权表示允许建立系统 VPN 配置，不证明远端已经可达。

5. 验证连接

   在 Home → Global Routing 临时选择 Proxy，启动连接并访问自己有权访问的测试目标。验证完成后恢复原先的 Global Routing 设置，再检查日常分流。

Global Routing 下的 Proxy 可用于减少规则变量，但仍不能绕过服务器本身的访问权限和网络限制。Direct 不适合验证 WireGuard 是否承载流量；Config 则需要确认测试目标确实命中使用该服务器的策略。系统显示 VPN 已连接，只代表本地隧道状态，不等同于完成远端密钥协商或业务访问成功。

五、DNS 与 MTU 怎么填：先沿用，再单独调整

DNS 决定域名如何解析，不负责修复密钥错误。传统 WireGuard 配置中的 DNS 常由使用该配置的应用解释，不是协议握手字段。将 WireGuard 参数手动录入 Shadowrocket 时，不应假设原文件中的 DNS 会自动成为当前配置的解析器；还要检查 Settings → DNS 以及当前 Config 中的 DNS 设置，以实际启用的配置为准。

• 若 Endpoint 使用域名，连接建立前就需要能解析这个域名。若唯一可用的解析器位于尚未建立的隧道内部，可能形成解析依赖，应先核对原配置的解析设计。
• 如果按 IP 访问某个受控目标正常，而按域名失败，优先检查 DNS；但 HTTPS 直接访问 IP 可能因证书或虚拟主机配置失败，不能把这一现象单独作为结论。
• 若内部域名必须由服务方指定的 DNS 解析，照抄其他网络的解析器可能让隧道已通却无法访问内部资源。

MTU 是接口允许承载的最大报文大小。WireGuard 还会增加外层封装开销，因此底层路径能承受的大小会限制隧道内报文。填得过大时，可能出现小请求正常、大页面或上传停住的现象；填得过小则增加分包与处理开销。此类现象也可能由丢包或服务器负载造成，不能只凭“加载慢”就确定是 MTU。

每轮测试记录网络类型、原 MTU、调整值以及同一操作的结果。如果降低后没有稳定改善，恢复原值，再查 UDP 可达性、丢包和服务端路由。不要同时换 DNS、改端口和降低 MTU，否则即使恢复访问，也无法判断真正原因。

六、按故障现象排查：从密钥到路由逐层检查

排障顺序应从连接基础条件开始，再看业务访问。端口可达、密钥匹配、地址正确、对端转发与返回路径成立后，DNS 和分流检查才有意义。如果服务端由用户自行管理，可同时查看对端最近握手时间和收发计数；若由已有服务方管理，提供脱敏后的时间与现象即可。

若 Proxy 下测试正常，恢复 Config 后失败，应检查实际命中的规则和策略，而不是重新生成 WireGuard 密钥。例如 DOMAIN-SUFFIX,example.com,PROXY 只匹配 example.com 及其子域名；IP-CIDR 按地址网段匹配，GEOIP 按 IP 地理数据库匹配，FINAL 用于未被前面规则匹配的连接。规则自上而下处理，目标使用哪个策略需要结合当前配置确认。