Shadowrocket WireGuard 配置:PrivateKey、PublicKey、AllowedIPs 等字段含义

介绍如何在 Add Server 中选择 WireGuard 类型,逐项解释密钥、地址、端点、MTU 与 AllowedIPs 等字段,并列出常见填写错误。

本文速览

配置 WireGuard,先区分本机身份、远端身份和隧道地址,再核对 Endpoint 与 AllowedIPs。本文面向已经持有自己的服务商配置或自管端点资料的用户,说明如何把标准 WireGuard 字段对应到 Shadowrocket 的添加流程,以及如何区分密钥错误、UDP 不通、路由范围不足和 MTU 不合适。

一、从 Add Server 添加 WireGuard

Shadowrocket(小火箭)中的 WireGuard 记录需要一组相互配套的参数。只有远端地址和端口并不足以完成连接:本机 PrivateKey 对应的 PublicKey 必须已在远端登记,隧道地址和允许的地址范围也必须与远端配置一致。下文使用的地址仅用于说明字段,不能直接连接。

  1. 整理参数

    从已有配置中区分 [Interface] 与 [Peer]:前者包含本机 PrivateKey、Address 等信息,后者包含远端 PublicKey、Endpoint、AllowedIPs 等信息。先保存原始资料,避免覆盖后无法对照。

  2. 选择类型

    进入 Home → 右上角「+」→ Add Server → Type,选择 WireGuard。确认 Type 后再填写参数,不能把 WireGuard 密钥填入其他协议的密码栏。

  3. 对应字段

    将 Endpoint 的主机与端口对应到 Address、Port;将 Interface 的 PrivateKey 和 Peer 的 PublicKey 对应到各自的密钥项。隧道 IP 应填入本地地址类字段,而不是远端 Address。具体分组和字段显示以当前应用界面为准。

  4. 保存验证

    保存后回到 Home,选中该记录,检查 Global Routing,再打开连接开关。按系统提示允许添加 VPN 配置后,用 Connectivity Test 和实际目标访问分别检查,不把开关开启等同于远端握手成功。

手动新增一条记录适合逐项核对。若记录来自已有订阅,先确认更新是否会重写手动修改;排查时保留独立副本,并标注修改内容。本站不提供、不销售、不推荐节点或订阅,以下步骤只处理用户已有的配置。

二、PrivateKey 与 PublicKey:先确定属于哪一端

WireGuard 的身份验证使用密钥对。本机 PrivateKey 与本机 PublicKey 是一对;远端也有自己的一对。Shadowrocket 中填写的 Peer PublicKey 是远端公钥,不是由当前 PrivateKey 派生出的本机公钥。这是手动配置时最容易颠倒的一项。

本机 Interface

PrivateKey
本机私钥,用于本机身份;应保密保存。
PublicKey
由本机 PrivateKey 派生,交给远端登记为 Peer。
Address
本机隧道地址,例如 10.66.0.2/32,不是公网端点。

更换本机 PrivateKey 后,远端登记的本机 PublicKey 也要同步更换。

远端 Peer

PublicKey
远端公钥,填入客户端对应的 Peer PublicKey 项。
PresharedKey
可选的额外共享密钥;启用时两端必须一致。
Endpoint
远端可达的主机与 UDP 端口,例如 192.0.2.10:51820。

客户端不需要远端 PrivateKey;不要交换两端的私钥。

标准 WireGuard 密钥是 32 字节数据的 Base64 表示,通常显示为 44 个字符并以 = 结尾。粘贴时保留末尾字符,不加引号,不带空格或换行。长度和外观正确只能说明格式可能成立,不能证明密钥属于正确的 Peer。

三、Address、Endpoint 与 DNS:三种地址不能混填

标准配置文件的 Address 表示隧道内部地址,而添加服务器界面的 Address 通常承担远端主机地址的作用。同一个英文词在不同上下文中含义不同,应结合所在分组辨认。将 10.66.0.2/32 填成远端主机,并不能让客户端找到公网端点。

配置内容示例及含义填写时核对
Interface Address10.66.0.2/32:本机隧道 IPv4 地址。按来源填写本地地址项;前缀长度与地址一同核对。
Peer Endpoint192.0.2.10:51820:远端主机与 UDP 端口。若界面分为 Address、Port,分别填写主机和 51820。
IPv6 Endpoint[2001:db8::10]:51820:组合写法以方括号区分主机与端口。主机与端口分栏时,不把完整组合串填入主机栏。
DNS负责名称解析的服务器地址或解析设置。确认解析路径能够到达;DNS 不代替 Endpoint 或隧道地址。

192.0.2.10 和 2001:db8::10 是文档示例地址。实际端口必须使用自己的配置,51820 只是常见示例,不是 WireGuard 强制端口。WireGuard 使用 UDP,因此普通 TCP 端口测试成功或失败,都不能直接证明该 UDP 端点可用。

如果 Endpoint 使用域名,客户端需要先解析它才能发送握手数据。若连端点域名都无法解析,应先检查当前网络的解析条件;若端点可达而只有网站域名访问失败,再检查 DNS 请求的实际去向。不要把这两种故障合并成“密钥有问题”。

四、AllowedIPs 与 Global Routing:两层选择分别检查

AllowedIPs 在 WireGuard 的 Peer 语义中用于关联地址范围与 Peer,也用于校验接收数据的源地址范围。它不是应用域名规则,更不是“允许连接的远端服务器清单”。例如 10.66.0.0/24 只描述一个 IPv4 网段,0.0.0.0/0 描述全部 IPv4 地址,::/0 描述全部 IPv6 地址。

Shadowrocket 的 Global Routing 与 WireGuard 的 Peer 地址范围不是同一个开关。临时选择 Proxy 可用于缩小规则因素的影响,但仍受应用处理范围、隧道参数和远端网络能力约束;选择 Direct 则不能验证 WireGuard 转发路径。完成测试后恢复原有姿态,避免把临时排查状态当成长期配置。

五、MTU 与 PersistentKeepalive:按症状调整

MTU 影响隧道内数据包的大小上限。封装会增加开销,可用值取决于底层网络及路径。只有“小请求成功、大页面或较大传输停顿”等现象与包长问题相符时,才值得对比 MTU;单纯握手失败应先检查 Endpoint、UDP 和密钥。

保留原始 MTU 设置

推荐

先使用已有配置提供的值;原配置未指定时,保留应用默认处理。记录当前网络、目标和现象,建立后续对照,不把某个常见数值当成所有网络的标准答案。

适合:首次配置、尚无包长异常证据的情况。

小幅降低 MTU

若原值为 1420,可在保留副本后以 1380 做一次对照测试;这只是排查示例,并非实测结论。保持同一网络、同一目标与其他参数不变,没有改善就恢复原值。

适合:已有数据交换,但较大传输反复停顿的情况。

PersistentKeepalive 的单位是秒,用于定期发送保活数据,帮助维持 NAT 或防火墙中的映射。25 是常见配置示例,但应以自己的配置需求为准。它不是重新认证密码,也不是速度开关;设置后无法修复错误的 PublicKey 或不可达的端口。

六、两端如何对应:客户端与远端核对清单

一端显示已开启连接,并不代表另一端已经接受该身份。排查时应分别确认客户端发给谁、远端允许谁,以及返回流量如何找到本机。尤其不要在多台设备上直接复用同一套身份与隧道地址,否则远端可能在不同来源端点间更新映射,表现为连接时断时续。

核对方案:本机 Interface 与远端 Peer 成对检查

Shadowrocket 本机
  • PrivateKey 属于当前设备,对应的 PublicKey 已交给远端登记。
  • Peer PublicKey 属于目标远端,Endpoint 主机与 UDP 端口均正确。
  • 隧道地址、地址范围和 DNS 与已有配置一致。
  • Home 选中正确记录,Global Routing 符合测试目的。
远端配置
  • 对应 Peer 登记的是当前设备 PublicKey,而非另一台设备的公钥。
  • 为本机分配独立地址,例如 10.66.0.2/32,并配置返回路径。
  • 实际监听的 UDP 端口与防火墙放行端口相符。
  • 需要访问外部网络时,具备相应转发、路由及访问权限。

先核对身份配对,再核对地址与转发;客户端改一个字段,不能替代远端的对应配置。

七、常见填写错误与验证方法

Connectivity Test 用于辅助判断可达性,不应把单个延迟值当成吞吐量或握手状态。验证时保留目标、测试方式和底层网络三项记录;如果远端由自己管理,再结合远端最近握手时间与收发计数确认数据是否到达。以下问答按可观察现象处理,不预设所有失败都来自同一个字段。

PrivateKey 一保存就报错,先改哪里?

回到 Home 中该记录的编辑页,检查是否复制了 PrivateKey = 整行、引号或换行。字段通常只需要等号后面的密钥值,末尾的 = 属于 Base64 内容,应保留;不要靠随意补字符修复。

开关打开了,为什么仍然没有数据?

先确认 Home 选中的是目标记录,再检查 Global Routing。随后核对 Endpoint、UDP 端口和远端 PublicKey;有远端管理权限时检查最近握手与收发计数。系统 VPN 已启动只能说明本地隧道已建立,不能独立证明远端已响应。

内部地址能访问,公网网页却打不开?

先核对 AllowedIPs 是否只覆盖内部网段,再分别检查 DNS 与远端转发条件。若 Global Routing 为 Config,还要检查实际目标命中的规则。不要仅将 AllowedIPs 改为全部地址,就认定远端已经具备公网转发能力。

关闭后又自动连接,字段填错了吗?

先到 Settings → On Demand 检查当前按需连接条件,手动排查时暂停相关自动触发,再回 Home 重测。On Demand 决定何时触发连接,与 WireGuard 密钥是否正确是两类问题,不应通过更换密钥处理自动连接。

另一台设备能用,能复制整套参数吗?

先确认远端是否为两台设备分别分配身份与地址。应使用各自的 PrivateKey,并在远端登记各自的 PublicKey;只复制相同的端点资料不等于复制整套身份。保留独立配置后,再在同一网络下做对照。

最终验收至少包含三项:目标请求确实走向预期记录、所需地址范围可以访问、空闲后恢复通信符合预期。完成后保留原始配置与修改记录,删除排查过程中临时创建的重复条目;如果使用订阅管理,还应确认下一次更新不会覆盖已核实的参数。

App Store 正版核对查看获取与购买说明