填写 WireGuard 的关键是分清本机与远端:Private Key 属于本机,Peer 的 Public Key 属于远端,Endpoint 是远端公网地址,Address 是本机隧道地址。本文以用户已有的 WireGuard 配置为前提,说明如何在 Shadowrocket(小火箭)中对应填写,并用 Allowed IPs、路由姿态与 DNS 三层检查定位“已打开开关但无法访问”的原因。
一、添加前先区分 Interface 与 Peer
标准 WireGuard 配置通常由 [Interface] 与 [Peer] 两部分组成。前者描述本机身份及隧道地址,后者描述要连接的对端。Shadowrocket 中即使字段排布与配置文件不同,也应按这两个归属逐项对应,不能把两侧的密钥对调。
先准备用户已有服务商提供的完整配置,并确认它仍然有效。只有一个 Endpoint 或一串 Public Key 不足以建立连接;服务端还需要登记与本机 Private Key 对应的 Public Key,并允许使用分配给本机的隧道地址。本文只说明已有配置的导入与检查,不提供、销售或推荐任何连接服务。
结论:先按归属分组,再填写字段
把原配置中的 Interface 与 Peer 分别核对一遍;只要无法确定某个密钥属于哪一侧,就先向配置提供方确认,不要通过交换密钥反复试连。
二、在 Add Server 中按顺序填写
以下操作以 iPhone / iPad 的 Home 页面为说明基准。进入 Home → + → Add Server → Type → WireGuard 后,先录入本机信息,再处理 Peer。若当前界面把 Endpoint 拆成地址与端口,或把 Peer 放在单独的编辑区域,应按字段含义填写,不要把整段配置文本粘进某个地址框。
-
选择类型
在 Home 点击右上角「+」,进入 Add Server,把 Type 设为 WireGuard。为记录填写便于辨认的备注,避免与原有服务器混淆。
-
填写本机
将 Interface 中的 PrivateKey 对应到 Private Key,将 Address 对应到本机隧道地址。保留地址后面的前缀长度,例如
10.66.0.2/32。 -
填写对端
进入 Peer 对应区域,填入 Peer 的 PublicKey 与 Endpoint。若分别显示地址和端口,则把主机地址与数字端口分开填写。
-
核对选项
按原配置检查 Allowed IPs、Preshared Key、MTU、DNS 与 Persistent Keepalive;未提供的可选字段不要从其他账户的配置中复制。
-
保存测试
保存后返回 Home,用圆点选中这条服务器,再打开连接开关;首次使用按系统提示允许添加 VPN 配置,随后执行 Connectivity Test。
若服务器由订阅生成,优先核对订阅里的原始参数。更新订阅可能重新生成条目,覆盖手动修改;需要排查时先记录原值,避免更新后误以为修改仍然保留。不要把普通订阅地址当成 WireGuard 的 Endpoint。
三、Private Key、Public Key 与 Preshared Key 分别填什么
Private Key 是本机私钥。它来自 Interface 的 PrivateKey,不应发送到公开讨论区或截图中。WireGuard 常用的 Base64 密钥文本通常为 44 个字符,但字符数正确只代表形式可能正确,不代表它与服务端登记的信息一致。
| 原配置位置 | 填写对应项 | 核对重点 |
|---|---|---|
| Interface / PrivateKey | Private Key | 本机私钥;完整复制,避免空格与换行 |
| Interface / Address | 本机隧道地址 | 不是公网 Endpoint;保留 CIDR 前缀 |
| Peer / PublicKey | Peer 的 Public Key | 远端公钥;不是本机公钥 |
| Peer / PresharedKey | Preshared Key | 可选的预共享密钥;两端必须一致 |
| Peer / Endpoint | 远端地址与端口 | 指向可访问的远端 UDP 服务 |
Peer 的 Public Key 是远端公钥。不要把由本机 Private Key 推导出的本机 Public Key 填到这里。本机 Public Key 用于让远端识别这台设备;Peer 的 Public Key 则用于让本机识别远端,两者用途相反。
Preshared Key 是额外的预共享密钥。原配置没有提供时通常留空;一端填写、另一端未配置,或两端内容不一致,都会导致握手失败。它不是登录密码,也不能用订阅 token 替代。
四、Endpoint 与 Allowed IPs:地址和路由不是一回事
Endpoint 表示远端实际接收 WireGuard UDP 数据包的位置,例如 192.0.2.10:51820。这里使用的是文档示例地址,不能用于连接;51820 也只是常见端口,不是必须值。原配置写什么端口,就填什么端口,不能擅自换成 443。
- 若界面分成地址与端口两栏,地址栏只填主机名或 IP,端口栏填十进制端口号。
- 若 Endpoint 使用域名,建立连接前必须能解析这个域名;解析失败时还没有进入 WireGuard 握手阶段。
- 若使用合并写法,IPv6 Endpoint 需要用方括号区分地址和端口,例如
[2001:db8::10]:51820,该地址同样仅供文档说明。 - Address 是隧道内部的本机地址,Endpoint 是远端入口,两者不能互换。
Allowed IPs 对应原配置的 AllowedIPs,描述该 Peer 关联的隧道内 IP 范围。WireGuard 用它选择发送到哪个 Peer,并检查接收数据包的来源地址是否属于该 Peer。它不是“允许访问的网站域名列表”,也不能直接填写 example.com。
0.0.0.0/0
::/0
10.20.0.0/16
上面三行分别表示全部 IPv4、全部 IPv6、一个指定 IPv4 网段,是三种范围示例,不是要求全部照抄。已有配置若只允许 10.20.0.0/16,把它改成全地址范围也不会自动获得远端的互联网转发能力。远端仍需具备对应路由、转发与访问权限。
五、MTU、DNS 与 Persistent Keepalive 的处理顺序
MTU 决定隧道接口可承载的 IP 数据包大小,不是带宽上限。原配置给出 MTU 时先沿用;没有给出时先使用默认处理,不要一开始就反复修改。外层网络的封装与路径 MTU 不同,某个数值可用并不意味着它适用于所有网络。
| 参数 | 作用 | 操作依据 |
|---|---|---|
| MTU | 限制隧道数据包大小 | 小请求正常、大请求停滞时再排查;例如从 1420 调至 1380 后复测同一目标 |
| DNS | 指定域名解析所用的服务器 | 确认解析器地址可经当前路由到达,并检查实际生效的 DNS 设置 |
| Persistent Keepalive | 定期发送保活包,帮助维持 NAT 映射 | 按原配置填写;25 秒是常见示例,不是必填值 |
DNS 不是 WireGuard 握手协议的一部分,配置文件里的 DNS 常由客户端或配置工具处理。因此,不能仅凭原文件写了 DNS 就认定 Shadowrocket 当前正在使用它。应同时核对条目中的 DNS 参数,以及 Settings → DNS 中的设置;若当前 Config 文件包含 DNS 设置,也要确认其生效关系。
若 DNS 地址是隧道内地址,例如 10.66.0.1,需要确认 Allowed IPs 覆盖它,并且相应连接确实被送入隧道。否则会出现 Endpoint 可达、隧道可能已建立,但域名解析仍超时的现象。不要只更换解析器,却忽略解析器本身的可达路径。
- 调整 MTU 时一次只改一个值,重新连接后对同一个目标执行同类请求,记录是否改善。
- 小请求成功、大文件停滞只是 MTU 排查线索,也可能与远端转发或目标服务有关,不能据此直接下结论。
- Persistent Keepalive 有助于维持空闲连接映射,但不能修复错误公钥、错误端口或远端未登记本机公钥的问题。
六、验证时先区分 Proxy、Config 与 Direct
Home 的连接开关已打开,只说明客户端连接流程已启用,不等于所有目标都通过 WireGuard。测试前先用圆点选中刚保存的条目,再检查 Global Routing。下面比较的是 Shadowrocket 自身的路由姿态,而不是协议速度。
Proxy:先隔离规则影响
推荐临时将受客户端接管的连接交给所选代理路径,减少 Config 分流规则对本次测试的影响。它不能扩大 Allowed IPs 范围,也不能补齐远端转发能力。
适合:首次验证具备互联网转发能力的 WireGuard 配置
Config:核对规则命中
按当前启用的配置文件分流。先确认目标命中了哪条规则及其策略,再判断连接是否应交给 WireGuard;最后的 FINAL 处理前面未匹配的连接。
适合:基础连接确认后恢复日常规则分流
Direct:建立直连对照
采用直连路径。此时网页能够打开不能证明 WireGuard 可用,但可以帮助判断目标是否本来就能通过当前网络访问。
适合:区分本地网络问题与隧道路径问题
Global Routing 中的 Scene 用于按所配置的场景处理路由,排查时也应确认它实际采用的策略,而不是只看姿态名称。若连接在手动断开后自动恢复,再检查 Settings → On Demand;On Demand 控制按需连接行为,不会修复 WireGuard 参数错误。
- 记录当前 Global Routing 姿态,选中待测服务器,打开连接后执行 Connectivity Test。
- 测试一个属于当前 Allowed IPs 范围、且已知允许访问的目标;仅提供内部网络访问的配置应测试内部服务。
- 如有可用的握手或流量记录,区分“没有完成握手”和“握手后业务不通”;单个延迟数字不能替代业务验证。
- 恢复 Config 后再次访问同一目标,核对规则策略、DNS 与连接结果是否发生变化。
七、填写后常见问题与处理方法
Private Key 保存成功,为什么还是连不上?
保存成功只说明输入可被接受。回到 Home 编辑该条目,核对 Interface 的 PrivateKey、Peer 的 PublicKey 与 PresharedKey 是否各归其位,再确认远端登记的是这份私钥对应的本机公钥。
Endpoint 端口是不是都填 51820?
不是。51820 只是常见示例,必须使用已有配置提供的 UDP 端口。若地址与端口分栏,不要把冒号和端口一起放入地址栏;换到另一条可信网络测试,也有助于区分当前网络的 UDP 可达性问题。
能访问内部地址,但普通网页打不开怎么办?
先看 Allowed IPs 是否仅包含内部网段,再确认服务本来是否提供互联网转发。若预期应能访问公网,则继续检查 Global Routing 与 DNS;不要直接把全部地址范围加进去当作通用修复。
订阅更新后,手动改过的 MTU 又变回去了?
订阅条目可能在更新时按远端内容重新生成。先对照更新前记录确认参数变化,再通过已有服务的配置来源调整;若另建手动测试条目,应使用清楚的备注,避免选回被更新的那一条。
完成排查后,保留必要的字段检查记录即可。分享问题时应隐藏 Private Key、Preshared Key、订阅 token 等敏感信息;若需要展示地址和错误现象,也应先移除与账户身份有关的内容。按“身份密钥 → Endpoint → Allowed IPs → DNS → MTU”的顺序逐项验证,比同时修改多个字段更容易找到原因。