配置 WireGuard 时,先分清本机 Interface 与远端 Peer:Private Key 属于本机,Peer 的 Public Key 属于远端,隧道 Address 也不是服务器 Endpoint。本文适合已有合法可用 WireGuard 配置的用户,按字段映射、添加步骤和故障现象逐项说明,帮助在 Shadowrocket 中复核密钥、地址、UDP 端口、MTU 与 DNS,而不是靠反复更换参数试错。
先区分 Interface 与 Peer
WireGuard 配置通常由 [Interface] 和一个或多个 [Peer] 段组成。Interface 描述本机的隧道身份与地址;Peer 描述与本机通信的另一端。把服务商提供的配置录入 Shadowrocket 时,应先按这两个角色整理字段,再进入 Home 添加记录。不要只看字段名里有没有 Key 或 Address 就直接粘贴。
本文以用户已有自己的服务商与配置为前提。Shadowrocket 是闭源商业应用,客户端买断 ≠ 线路套餐;本站不提供、不销售、不推荐节点或订阅。WireGuard 的字段有效性取决于两端配置是否配套,应用购买本身不会生成可用的远端 Peer。
Interface 本机侧
- Private Key
- 本机私钥,对应原配置的 PrivateKey。
- Address
- 分配给本机的隧道 IP 与前缀长度。
- MTU
- 隧道接口允许的最大 IP 包大小。
- DNS
- 配置指定的解析器地址,需确认实际生效范围。
本机密钥与隧道地址应来自同一份有效配置。
Peer 远端侧
- Public Key
- 远端公钥,对应 Peer 段的 PublicKey。
- Endpoint
- 远端服务器地址与 UDP 端口。
- AllowedIPs
- 该 Peer 对应的隧道地址范围。
- Preshared Key
- 双方约定的可选预共享密钥。
不要把本机公钥填入远端 Public Key。
Private Key、Public Key 与 Preshared Key
PrivateKey 与 PublicKey 是成对使用的身份材料。本机私钥会对应一个本机公钥,远端必须登记这个本机公钥;与此同时,本机配置中 Peer 的 Public Key 应当是远端公钥。这是两端互相识别的关系,不是将同一个公钥复制到所有位置。
WireGuard 标准密钥是 32 字节数据,常见文本形式为 44 个字符的 Base64 字符串,通常以 = 结尾。长度符合只能说明外观合理,不能证明它属于当前账户或当前 Peer。复制时应保留结尾字符,去掉意外的引号、换行和前后空白,不要把整行 PrivateKey = 一并填进只接收密钥值的输入框。
- Private Key:从原配置的 Interface 段复制,不能用 Public Key 替代,也不应在公开截图或求助记录中展示。
- Public Key:从目标 Peer 段复制。若远端更换密钥,需要同步更新,而不是仅修改服务器地址。
- Preshared Key:是可选的额外对称密钥;原配置提供时必须两端一致,未提供时不要自行生成后单方面填入。
- 重新生成本机私钥:会改变对应的本机公钥。除非远端也更新登记信息,否则原有授权关系不会自动延续。
Address 与 Endpoint:两个地址不能互换
Interface 的 Address 是隧道内地址,例如 10.66.0.2/32。其中 /32 是 IPv4 前缀长度,不是端口。Endpoint 则是建立 WireGuard 通信时需要访问的远端网络地址,通常表现为域名或 IP 加 UDP 端口。两者承担不同任务,即使界面中都出现 Address,也必须结合所在层级判断。
| 原配置内容 | 含义 | 录入检查点 |
|---|---|---|
Address = 10.66.0.2/32 | 本机隧道 IPv4 地址 | 填入本机隧道地址项,按输入框要求保留前缀。 |
Address = fd66::2/128 | 本机隧道 IPv6 地址 | 仅在原配置分配该地址时填写,不凭空补齐。 |
Endpoint = 192.0.2.10:51820 | 远端 IPv4 地址与 UDP 端口 | 分开的输入框中,Address 填 IP,Port 填 51820。 |
Endpoint = [2001:db8::10]:51820 | 远端 IPv6 地址与 UDP 端口 | 整串表示时用方括号区分 IPv6 与端口;分栏时按字段格式输入。 |
表中的地址仅用于说明格式,不能作为实际服务器使用。端口 51820 是常见配置值,不是必须值;如果原配置写的是其他端口,应照填原值。Endpoint 不应加 https://,也不能填成订阅链接。若使用域名,本机需要先具备解析该域名的条件,之后才能向远端发送 WireGuard 握手报文。
在 Home 添加并做一次单项验证
先保留一份原始配置,再操作应用。以下步骤针对已有 WireGuard 参数的手动录入;若参数由已有订阅管理,应先确认该记录是否会在更新时被覆盖。不同界面布局可能将隧道参数展开为独立项目,核对时以 Interface 与 Peer 的归属为准,不把配置文件中的段落标记当作字段值。
-
整理参数
分别抄录 Interface 的 PrivateKey、Address,以及 Peer 的 PublicKey、Endpoint;有 PresharedKey、MTU、DNS 时一并保留。包含多个 Peer 的配置应先确认具体需要录入哪一个。
-
选择类型
进入 Home → 右上角「+」→ Type → WireGuard,再填写该记录的备注和远端地址信息。备注只用于识别记录,不参与密钥认证。
-
核对角色
填入本机 Private Key、隧道 Address 与远端 Public Key,按原配置补充其余参数。保存前逐项比对,尤其检查 Endpoint 的 Port 是否被误写成隧道前缀长度。
-
隔离测试
回到 Home 选中该记录,临时将 Global Routing 设为 Proxy 后开启连接,访问一个已知可达的目标。测试结束恢复原来的 Global Routing,避免将临时姿态保留为日常配置。
-
检查自动连接
若手动断开后又重新连接,检查 Settings → On Demand。测试期间先停用可能触发自动连接的条件,完成验证后恢复需要的设置。
系统 VPN 状态显示连接,并不等于远端握手已成功。它首先说明本机 VPN 会话已建立;远端是否能够收发数据,还需要结合实际请求结果、可用的握手记录与收发计数判断。不要因为开关已经打开,就跳过密钥与 Endpoint 的检查。
AllowedIPs 与 Global Routing 的职责
在标准 WireGuard 配置中,AllowedIPs 将地址范围关联到指定 Peer,并参与接收数据时的源地址校验。0.0.0.0/0 表示全部 IPv4 地址范围,::/0 表示全部 IPv6 地址范围;这两个值本身不保证远端提供对应协议族的转发能力。
Shadowrocket 的 Global Routing 则决定应用如何选择请求的处理路径。Proxy 用于代理姿态,Direct 用于直连姿态,Config 按当前配置处理,Scene 按所选场景处理。AllowedIPs 不是 Config 中的域名规则,不能将 DOMAIN-SUFFIX 或 FINAL 写进它的地址列表。
- Proxy 下可用,Config 下不可用:先核对当前 Config 的规则命中结果、目标策略及所选服务器,不能立即认定 WireGuard 字段错误。
- Direct 下可用:只能说明目标通过当前直连网络可达,不能作为该 WireGuard Peer 正常工作的证据。
- 仅 IPv6 目标失败:检查隧道 IPv6 地址、Peer 的地址范围与远端 IPv6 转发条件是否完整。
- 多 Peer 原配置:不要把多个 Peer 的 Public Key、Endpoint 和 AllowedIPs 混合成一条记录;保留原有一一对应关系。
MTU:先用原值,再根据现象调整
MTU 决定隧道接口能承载的最大 IP 包大小。WireGuard 在 UDP 中封装数据,外层还需要 IP、UDP 与协议本身的空间。对于不含额外扩展的常见数据封装,外层 IPv4 的开销约为 60 字节,外层 IPv6 约为 80 字节;实际可用值仍受接入网络和整条路径约束。
1420 是常见参考值,而不是所有网络的最佳值。若原配置明确提供 MTU,先照填;若没有提供,优先保留应用默认处理。只有在握手与小请求正常、较大页面或上传持续停滞时,才将 MTU 纳入排查,不能用降低 MTU 代替修正错误密钥。
- 记录当前 MTU 与复现目标,分别测试同一网络下的小请求、较大页面和上传。
- 在其他字段不变的前提下,例如从 1420 调到 1380,重新连接后重复相同请求。这是排查示例,不是实测结论。
- 若现象没有改善,恢复原值,继续检查 UDP 可达性、DNS 和远端转发;若有改善,再验证 Wi-Fi 与蜂窝网络切换后的表现。
DNS:区分 Endpoint 解析与隧道内解析
WireGuard 的加密协议本身不负责下发 DNS;常见配置中的 DNS 是由客户端处理的附加设置。将原文件中的 DNS 值录入后,还需要结合 Shadowrocket 当前 Config 的 DNS 配置确认实际解析路径,不能仅凭字段存在就认定所有查询一定走该解析器。
建立通信前解析 Endpoint 域名,与连接后解析网页域名,是两个阶段。如果 Endpoint 是域名,而指定 DNS 又只能通过尚未建立的隧道访问,就需要可用的初始解析路径。排查时先确认远端域名能在当前接入网络解析,再确认隧道内 DNS 是否可达,避免把这两类失败混在一起。
- 原配置使用内网 DNS 地址时,确认对应地址范围能够经目标 Peer 到达;内网解析器不一定可由直连网络访问。
- DNS 输入项若要求 IP 地址,就不要直接粘贴带
https://的解析服务 URL;不同格式不能互相替代。 - 访问域名失败而同一目标的 IP 路径可达时,优先检查解析;但直接用 IP 访问 HTTPS 可能因证书或站点选择失败,不能将此作为唯一判据。
- 已有订阅更新后若参数回退,重新核对记录来源和 Config,不要同时改密钥、DNS、MTU,导致无法定位是哪一项产生影响。
常见问题:按现象缩小范围
Private Key 填好了,为什么仍然没流量?
先比对 Peer 的 Public Key 与 Endpoint,再确认远端登记的是当前私钥对应的本机公钥。若原配置带 PresharedKey,也要照填。只有本机私钥正确,不能证明两端的身份关系已配对。
Port 一定要填 51820 吗?
不一定。以已有配置的 Endpoint 端口为准,并确认路径允许该 UDP 端口通信。只把端口改成 443 不会将 WireGuard 变成 HTTPS,也不会自动解决 UDP 被限制的问题。
小网页能打开,大页面一直转圈怎么办?
先在同一网络重复请求,确认不是特定网站故障;保持密钥和 Endpoint 不变,记录 MTU 后做一次降低测试。若仅域名请求失败,应同时核对 DNS,不要直接断定 MTU 是原因。
换到蜂窝网络后不能用,要重填密钥吗?
先检查当前网络的 UDP 可达性和 Endpoint 域名解析,再查看 Settings → On Demand 是否改变了连接行为。网络切换本身不要求更换密钥;若原配置提供 PersistentKeepalive,应按原值保留,它不能替代可达的 UDP 路径。
同一份配置能同时给两台设备用吗?
优先为每台设备取得独立的密钥与隧道地址。两台设备同时使用相同私钥时,远端可能随最近收到的认证报文更新 Endpoint,造成流量在设备间切换。不要用提高 MTU 或修改 DNS 处理这种身份复用问题。
完成后保留一份脱敏的核对记录:参数来源、所选记录、Global Routing 姿态、测试网络,以及修改前后的 MTU。恢复原有 Config 与 On Demand 设置后再做一次实际访问,确保临时测试结果能够延续到日常使用。