本文适合已有服务商和 WireGuard 配置、需要手动核对参数的用户。先将客户端身份与远端身份分开,再依次检查地址、端点、密钥、MTU 和 DNS,最后用固定的测试顺序区分握手失败、解析失败与规则选路问题。文中的地址仅用于解释字段,不是可连接的服务配置。
一、从 Home 新建 WireGuard 条目
Shadowrocket(小火箭)中的 WireGuard 条目需要一套相互对应的参数。仅有远端地址和端口并不足以连接:远端还必须登记与本机 Private Key 对应的公钥,并为该客户端分配隧道地址。本文以用户已经取得自己的合法配置为前提,不涉及服务来源选择。
在 Home 右上角点“+”进入 Add Server,先将 Type 设为 WireGuard,再核对该类型展开的字段。表单中的服务器地址、端口与密钥可能分栏显示;下文先解释端点,再解释密钥、隧道地址及高级参数。具体字段排列与是否显示可选项,以当前界面为准,不要把其他协议的 Password 或 UUID 填入 WireGuard 密钥栏。
-
准备配置
从自己的配置记录中找出 Interface 与 Peer 两部分,保留原始副本。PrivateKey 属于本机,Peer 中的 PublicKey 属于远端,两者不要互换。
-
选择类型
打开 Home → “+” → Add Server → Type → WireGuard。先确认类型,再填写地址和密钥,避免沿用上一种协议的字段含义。
-
逐项填写
按自己的配置填写服务器地址、端口、Private Key、远端 Public Key 和隧道地址;MTU、DNS 及可选密钥也应优先沿用原值。
-
保存测试
保存后返回 Home,选中该条目,再打开连接开关。首次使用时按系统提示允许添加 VPN 配置,并用 Connectivity Test 检查连通性。
二、Endpoint:把远端地址与端口分清
Endpoint 是 WireGuard 对端在公网可到达的位置,由主机名或 IP 地址加 UDP 端口组成。原配置可能把两者合写为 vpn.example.com:51820;如果 Add Server 分别显示 Address 与 Port,应将主机部分填入地址栏,将 51820 填入端口栏,不要把整段内容重复粘贴到两个字段。
| 原始文本示例 | 主机部分 | 端口部分 |
|---|---|---|
vpn.example.com:51820 | vpn.example.com | 51820 |
192.0.2.10:51820 | 192.0.2.10 | 51820 |
[2001:db8::10]:51820 | 2001:db8::10 | 51820 |
上表使用文档示例域名和地址,不能用于实际连接。IPv6 的方括号用于在合写形式中区分地址和端口;分栏填写时,应遵循该地址字段的输入要求。不要在主机栏前面添加 https://,也不要附加网页路径。
51820 是常见示例端口,不是所有 WireGuard 服务都必须使用的端口。端口应以自己的配置为准。WireGuard 使用 UDP;某个地址上的 TCP 端口可访问,不能证明同一数字的 UDP 端口可用。若域名无法解析、端口写错或当前网络限制 UDP,常见结果是持续没有可用响应,但仅凭这一现象还不能判断是哪一项错误。
三、Private Key、Public Key 与可选密钥
Private Key 是本机的私钥。它决定本机公钥,而远端需要事先认可该公钥。Public Key 在远端配置项中通常指对端的公钥,用来识别服务器,不是让用户把自己从 Private Key 推导出的公钥再填一遍。两项都可能表现为较长的 Base64 文本,因此不能只凭外观判断归属。
结论:先核对密钥归属,再考虑重建
将本机 Private Key 与远端 Public Key 分别对照原配置;不要为了排错直接生成新私钥。更换私钥后,远端登记的客户端公钥也必须同步调整,否则原来正确的端点仍无法完成认证。
- Private Key:复制时避免带入字段名、引号、换行和首尾空格。不要将真实私钥写入公开反馈、截图或测试文本。
- Public Key:使用自己的服务配置中 Peer 对应的公钥。它不是服务器域名、账户密码,也不是订阅令牌。
- Pre-shared Key:如果配置和当前界面包含这一可选项,双方必须使用相同值;原配置未设置时,不要自行添加一个随机值。
长度正确只说明文本外形可能符合要求,不能证明密钥与远端匹配。公钥填错、私钥不对应、Pre-shared Key 不一致,都可能表现为无法建立有效通信。应逐项对照原始记录,不要把所有失败都归因于端口。
四、隧道地址:Address 不是 Endpoint
同样带有“地址”含义的字段可能承担两种完全不同的作用:Endpoint 的地址用于找到公网对端,Interface 中的 Address 则是本机在隧道内使用的地址。原配置中若出现 10.66.0.2/32,它表示客户端的内部地址及前缀长度,不应填到公网服务器主机栏。
| 配置概念 | 文本示例 | 填写时的判断 |
|---|---|---|
| Endpoint | vpn.example.com:51820 | 远端入口,主机与端口按界面拆分。 |
| Interface Address | 10.66.0.2/32 | 本机隧道地址,保留已分配的地址和必要前缀。 |
| IPv6 Address | fd00:66::2/128 | 仅在自己的配置分配了 IPv6 时填写。 |
| AllowedIPs | 0.0.0.0/0, ::/0 | WireGuard 的地址范围配置,不是 DNS,也不是密钥。 |
不要根据上述示例自行选择隧道地址。同一远端下的客户端地址通常需要避免冲突;沿用另一台设备的完整身份与地址,可能导致通信交替中断。若要同时使用多台设备,应使用服务端为各设备分配的独立配置。
AllowedIPs 也不能直接等同于 Shadowrocket 的全局选路模式。它在 WireGuard 中参与对端地址范围的处理,而 Shadowrocket 是否把某条应用连接交给该服务器,还取决于 Global Routing 和 Config 中的规则。原配置存在该项、但当前编辑页未提供同名字段时,不要将它粘贴到 Address 或 DNS 栏,应先核对当前受支持的导入方式与配置说明。
五、MTU 与 DNS:连接后仍异常时怎样检查
MTU 限制隧道接口处理的数据包大小。数值过大时,外层封装可能超过路径所能承载的大小;若路径上的分片或错误反馈处理不完整,可能出现小请求成功、较大请求停滞的现象。这是排查线索,不是单凭网页加载慢就能得出的结论。
- 先保持原值:自己的配置明确写了 MTU,就先使用该值;未指定时,优先保持应用默认行为,不要一开始同时改动多个高级参数。
- 单变量试验:例如原值为
1420,且已确认存在大包相关异常,可以临时以1380复测同一请求。这个数字是排查示例,不是通用最佳值。 - 记录结果:分别记录请求是否完成、是否超时以及所用网络。若没有稳定改善,恢复原值,继续检查解析、路由和远端状态。
DNS 用于把域名解析为地址,不负责修复密钥或端口错误。原 WireGuard 配置中的 DNS 常表示隧道使用的解析服务器;Shadowrocket 的实际解析行为还会受到 Config 中 DNS 设置及相关选路影响,不能认为在服务器条目中写入一个 DNS 地址后,所有域名查询就必然走同一路径。
内部 DNS 地址也必须在相应网络路径上可达。出现“按地址测试有响应、按域名请求失败”时,可以优先检查解析结果与 DNS 可达性,但仍应注意网站可能依赖正确的域名与 TLS 信息,不要用浏览器直接访问某个 IP 的结果代替完整的域名测试。
六、Global Routing:区分协议问题与规则问题
保存 WireGuard 条目后,Home 中还需要选中该服务器。连接开关开启表示系统已启用相应的 VPN 配置,并不等于远端已经成功响应。测试时先确认流量确实会交给该条目,否则可能出现“测试通过,但其实走了 Direct”的误判。
Config
推荐按当前配置文件的规则处理连接。核对目标命中的策略是否实际指向待测 WireGuard 条目;命中 DIRECT 的请求不能用于证明该条目可用。
适合:参数验证完成后,按已有规则进行日常分流。
Proxy
将接管的连接按代理姿态处理,可用于临时减少规则分流对测试的干扰。仍需确认选中的服务器,且不应把此模式理解为能够绕过系统所有流量边界。
适合:短时排查 Config 规则是否影响测试路径。
Direct
按直连姿态处理连接。它适合检查当前基础网络,但直连成功不能说明 WireGuard 的密钥、端口或隧道地址正确。
适合:建立基础网络对照,确认未经过代理时的现象。
若平时使用 Scene,也应先确认当前场景实际采用的服务器与规则,再解释测试结果。排查结束后恢复原有模式。检查 Settings → On Demand 时,重点确认按需连接条件是否会在测试期间触发连接状态变化;On Demand 不会替代 WireGuard 的身份认证,也不会纠正错误参数。
在 Config 中,DOMAIN-SUFFIX 可以匹配域名后缀,IP-CIDR 匹配地址段,GEOIP 按 IP 地理归属匹配,FINAL 处理此前未命中的连接。规则按顺序影响选路;因此应结合实际命中的策略检查,而不是仅凭 Home 顶部开关判断协议状态。
七、按现象逐项复核,不一次修改全部字段
先在一个稳定网络中保存基线,再使用 Connectivity Test 和实际业务请求交叉验证。单次延迟数字不代表所有目标都可达,测试失败也不能直接等同于密钥错误。下表用于安排检查次序,不用于凭一种现象断定唯一原因。
| 观察到的现象 | 优先检查 | 下一步操作 |
|---|---|---|
| 开启后请求持续超时 | Endpoint、UDP 可达性、双方密钥 | 对照原配置,逐项确认;可分别在 Wi-Fi 与蜂窝网络复测。 |
| 域名请求失败 | DNS 结果、解析路径、DNS 可达性 | 区分 Endpoint 域名解析与目标域名解析,核对当前 Config。 |
| 小请求成功,大请求停滞 | 路径 MTU、丢包、远端负载 | 保持目标与网络不变,仅调整 MTU 做对照,记录后恢复或保留有效值。 |
| 只有部分目标异常 | 规则命中、IPv4 与 IPv6 路径 | 确认是否使用同一服务器,不要立即重建密钥。 |
| 切换网络后才异常 | 新网络的 UDP、域名解析与连接状态 | 重新建立连接并复测,比较两个网络的差异。 |
如果条目来自用户已有的订阅,手动编辑的内容还可能在订阅更新后被覆盖。修改前保留原参数,并用明确的备注区分测试条目与订阅管理的条目。需要向自己的服务方反馈时,提供测试网络、错误现象和已核对的字段名称即可;真实 Private Key、Pre-shared Key 与完整订阅链接不应出现在公开记录中。
最终确认顺序是:远端入口可达、密钥归属正确、隧道地址对应、解析路径可用、目标流量确实命中该服务器。只有在这些基础项得到验证后,再讨论 MTU 微调,才能避免用高级参数掩盖基础填写错误。