Shadowrocket WireGuard 配置参数详解:PrivateKey、Endpoint 与 AllowedIPs

一、添加前先区分 Interface 与 Peer

Shadowrocket（小火箭）的 WireGuard 配置不能只靠一个服务器地址完成。常见 WireGuard 配置把信息分成 [Interface] 与 [Peer]：前者描述本机的密钥和隧道地址，后者描述通信对端的公钥、入口及允许的地址范围。把两部分的密钥填反，即使地址和端口正确，也无法完成正常认证。

本文以用户已有自己的服务商与配置为前提。添加前应拿到完整且相互匹配的参数；只有 Endpoint、没有本机 PrivateKey 或对端 PublicKey，不能构成可用配置。Shadowrocket 是闭源商业应用，客户端买断 ≠ 线路套餐，购买客户端不会自动生成可用的 WireGuard 对端。

二、在 Home 添加 WireGuard 并保留原始参数

手动添加从 Home → 右上角「+」→ Type → WireGuard 开始。选择协议后再填写，避免把 WireGuard 参数留在其他协议的表单中。下面使用 WireGuard 配置文件的标准字段名解释对应关系；应用表单可能把 Endpoint 拆成地址与端口，具体字段显示以当前应用内为准。

1. 整理配置

   保留一份原始配置，分别标出 Interface 的 PrivateKey、Address，以及 Peer 的 PublicKey、Endpoint、AllowedIPs。若有 PresharedKey，一并记录但不要放入公开笔记或截图。

2. 选择协议

   进入 Home →「+」→ Type → WireGuard。先确认 Type，再输入参数；不要把完整的配置文件文本粘贴进服务器地址栏。

3. 填写入口

   将 Endpoint 的主机与端口对应填写。例如 192.0.2.10:51820 表示主机 192.0.2.10、端口 51820；该文档示例地址不可用作实际入口。

4. 填写身份

   填写本机 PrivateKey、对端 PublicKey 和已分配的 Address，再按原始配置处理 AllowedIPs 及可选参数。密钥不要附带引号、字段名或换行。

5. 保存验证

   保存后回到 Home，选中该配置，核对 Global Routing，再开启连接。首次出现系统 VPN 配置授权时，核对应用后按系统提示操作。用一个已知允许访问的目标发起请求，并检查连接结果。

三、PrivateKey 与 PublicKey：长度正确不等于配对正确

PrivateKey 用于本机身份认证，对应的本机 PublicKey 需要登记在远端的 Peer 配置中。Shadowrocket 内填写的 Peer PublicKey 则应来自远端。两端不是互相交换私钥，而是各自保存私钥、使用对方公钥识别对端。

上述长度只用于检查明显的复制错误，不能证明密钥有效或属于同一连接。末尾的 = 可能是 Base64 填充，不应随意删除；聊天排版带入的空格、引号和换行则不属于密钥。也不要用外观相近的字符手工补齐缺失内容。

• 误用本机公钥：如果 Peer PublicKey 填成本机公钥，应从原始配置重新取得远端公钥，而不是反复重建连接。
• 只更换本机私钥：新 PrivateKey 对应新的本机 PublicKey，远端也必须同步登记，否则身份不匹配。
• 预共享密钥遗漏：原配置启用了 PresharedKey 时，不能只填写两端公私钥；该值不一致同样会阻止认证。
• 多设备复用身份：同一组身份在不同设备同时使用时，远端可能随收到的认证数据更新端点，造成连接相互干扰。应由配置管理方分配独立 Peer 与隧道地址。

四、Endpoint、Address 与 AllowedIPs 分别控制什么

Endpoint 是建立通信时访问的外层入口，Address 是本机在隧道内使用的地址，两者不能互换。例如远端公网入口使用端口 51820，并不意味着本机 Address 也要包含该端口。WireGuard 使用 UDP；入口只允许 TCP 通过时，填写同一个端口数字也不能替代 UDP 连通性。

在 WireGuard 协议层，AllowedIPs 参与选择出站数据对应的 Peer，也用于校验该 Peer 发来的数据所声明的源地址。它不是网站域名列表，不能写成 example.com，也不能直接放入 DOMAIN-SUFFIX 规则。只有 IPv4 默认范围而没有 IPv6 范围时，不应据此认定 IPv6 目标也已经覆盖。

• Endpoint 使用域名时，需要先能解析该域名，才有机会向远端发出握手流量。
• Address 的前缀长度不能仅凭习惯更改；/32 与 /24 表达的地址范围不同。
• 扩大 AllowedIPs 不会赋予远端原本没有的转发或访问权限，应先确认对端允许的用途。

五、Global Routing 与 WireGuard 不是同一层设置

Shadowrocket 先按自身的流量策略决定请求去向，WireGuard 参数再约束选中该连接后的通信。Global Routing 下的 Proxy、Direct、Config、Scene 不能与 AllowedIPs 画等号：Proxy 用于代理路径，Direct 用于直接连接，Config 按配置规则处理，Scene 按已配置的场景设置处理。具体结果还取决于选中的策略与配置。

首次验证时，可在了解影响范围的前提下短暂使用 Proxy，并选中待测 WireGuard 连接，减少规则分流对判断的干扰；验证后恢复原来的姿态。在 Config 下，即使 WireGuard 本身可用，请求若命中 DIRECT，也不会因为 AllowedIPs 写了默认范围就自动改走该 Peer。

DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY

这段是规则关键字示意，不是 WireGuard 配置，也不是要求覆盖现有 Config。DOMAIN-SUFFIX 匹配域名后缀，GEOIP 按 IP 地理库匹配，IP-CIDR 匹配 IP 网段，FINAL 接收未被前序规则匹配的请求。示例中的 PROXY 表示代理策略；实际使用时还要核对配置中的策略指向，不能只看规则末尾文字。

六、MTU 与 PersistentKeepalive 的调整边界

MTU 控制隧道接口发送的 IP 报文大小。WireGuard 封装还需要外层 IP、UDP 等开销，因此不能直接把底层链路的 MTU 原样照抄进隧道。1420 是常见的排查参考值，但不是适合所有路径的固定答案；应优先使用已有配置给出的值或应用默认处理。

1. 先确认基础连接。如果连握手都未建立，应先检查 Endpoint、UDP 网络和密钥，不要把 MTU 当作首要原因。
2. 记录可复现现象。例如小请求成功、较大响应反复停住，才需要进一步怀疑路径 MTU、丢包或相关网络限制。这只是排查线索，不是单凭现象就能确定的结论。
3. 一次只改一个值。可在配置方允许的范围内，分别以 1420、1380 进行对照；每次保存并重新连接，用相同目标与请求复测，记录原值以便恢复。
4. 避免无限减小。如果减小后没有改善，应回到 DNS、路由和对端状态检查，而不是持续降低数值。涉及 IPv6 时，还需满足其链路 MTU 约束。

PersistentKeepalive 用于周期性发送保活数据，帮助维持 NAT 映射。25 秒是常见配置示例，不是必须开启的协议要求；0 表示关闭周期性保活。它适合排查空闲一段时间后回程通信中断的情形，不能修复错误公钥、不可达端口或不受允许的目标网段。

• 配置文件给出的单位是秒，不要把 25 秒误填成毫秒数。
• 不是每个网络都需要同样的保活频率，应结合配置方要求与实际测试决定。
• 移动网络切换后需要复测；保活不能保证网络地址变化期间的所有请求连续成功。

七、按现象排查，而不是反复重建配置

每轮排查只改变一项，并记录测试网络、Global Routing 姿态、访问目标和结果。Home 中的延迟或连通性结果只能说明对应测试项目的表现；不同测试方式覆盖的环节不同，不能用单个延迟数值证明密钥、DNS、AllowedIPs 和所有业务请求都正常。