本文适合已有自己的 WireGuard 服务与配置、准备在 Shadowrocket 中核对参数的用户。先区分本机身份与远端身份，再对应 Address、Endpoint、DNS 和 MTU，最后分别验证连接、规则与网页访问。重点是解释每项参数由谁提供、填错会影响哪一层，而不是提供可直接连接的服务配置。
先区分 Interface 与 Peer
Shadowrocket（小火箭）中的 WireGuard 参数应来自用户已有服务的完整配置。标准 WireGuard 文本通常以 [Interface] 描述本机接口，以 [Peer] 描述远端。手动填写时，需要把这两部分对应到同一个 WireGuard 条目，不能把另一台设备的私钥、当前设备的 Address 和不同服务器的公钥拼在一起。
WireGuard 使用 UDP 承载隧道通信。服务器地址和端口只决定报文发往哪里，密钥决定通信双方是否能够相互认证。因此，“地址能解析”“端口填写正确”与“身份认证成功”是不同的检查项。
Private Key、Public Key 与 Preshared Key
[Interface] 中的 PrivateKey 是本机私钥，对应界面中的 Private Key。由它可以推导本机公钥，而远端需要登记这个本机公钥。本机私钥不是登录密码，也不是远端的公钥；更换私钥后，如果远端没有同步更新对应记录，原有配置就不能继续完成正常通信。
| 配置字段 | 填写含义 | 常见错误 |
|---|---|---|
Interface.PrivateKey | 本机持有的私钥，对应 Private Key。 | 填成服务端公钥，或复制时混入空格、引号。 |
Peer.PublicKey | 远端公钥，对应 Public Key。 | 填成本机公钥，导致远端身份不匹配。 |
Peer.PresharedKey | 双方额外约定的共享密钥，对应 Preshared Key。 | 一端设置而另一端未设置，或两端内容不同。 |
Public Key 要填的是对端公钥，不是“由本机 Private Key 算出来的那个公钥”。如果服务配置同时列出客户端公钥和服务器公钥，先看字段所属的部分：[Peer] 下的 PublicKey 才是此处需要核对的远端身份。
Preshared Key 是可选参数，但“可选”不等于可以单方面删除。原配置提供了该项，就应原样保留；原配置没有该项，不要自行生成一个填上。包含 +、/、= 的 Base64 文本需要完整复制，不要进行 URL 编码或把末尾的 = 当作多余标点去掉。
Address 与 Endpoint 不在同一层
Address 是隧道内分配给本机的地址，通常带有 CIDR 前缀长度。例如 10.66.0.2/32 表示一个 IPv4 接口地址；双栈配置还可能提供类似 fd00:66::2/128 的 IPv6 地址。这些仅为语法示例，不能代替服务端实际分配的值。Address 不是远端服务器地址，也不是设备当前 Wi-Fi 的局域网地址。
- Address：按原配置填写，保留
/32、/128等前缀长度。若界面将 IPv4 与 IPv6 分成独立字段，分别对应，不要把两项强行合并到单一地址框。 - Endpoint：远端可到达的域名或 IP 与 UDP 端口。例如文档地址
192.0.2.10:51820只演示结构，不是连接入口。 - 端口拆分：当界面分别显示 Address 与 Port 时，服务器地址框不附加端口，Port 单独填写。不要因常见示例使用
51820，就覆盖原配置中的其他端口。 - IPv6 Endpoint：标准文本中含端口的 IPv6 写法使用方括号，例如
[2001:db8::10]:51820；拆分到界面时，应按独立地址字段的格式要求填写。
标准配置还可能包含 AllowedIPs。它描述 WireGuard 对端关联的地址范围，并参与 WireGuard 的路由与来源地址检查；它不是 Address，也不能直接视为 Shadowrocket 的全局分流规则。是否在编辑页提供对应选项，应以实际显示的字段为准。不要因为看到 0.0.0.0/0，就断言 Shadowrocket 的所有请求一定经过该条目。
DNS 与 MTU：解析和报文大小分开检查
DNS 用于把域名解析成地址，不负责修复密钥错误。标准 WireGuard 文件中的 DNS 是客户端工具使用的配置约定，不是 WireGuard 握手报文中的认证参数。在 Shadowrocket 中，还要同时核对当前 Config 与 Settings 中生效的 DNS 设置，不能只凭原文件写了一个 DNS 地址，就认定运行时一定使用它。
| 参数 | 检查重点 | 可观察现象 |
|---|---|---|
DNS | 解析器是否可达，是否仅能通过隧道访问，Endpoint 域名能否先完成解析。 | 域名解析报错，但已知目标的连接测试可能仍有响应。 |
MTU | 先沿用原配置；隧道封装后是否超过实际路径可承受的报文大小。 | 小请求成功，大响应或上传停滞，部分网页长时间加载。 |
PersistentKeepalive | 原配置是否要求定期发送保活报文，当前网络是否存在 NAT 映射过期。 | 长时间空闲后首次访问失败，重新连接后短暂恢复。 |
MTU 的单位是字节。1420 是常见参考值，不是所有网络的固定最优值。如果原配置已经指定 MTU，先按原值验证；只有出现“大请求停滞、小请求正常”等可重复现象时，再一次只改这一项。例如将 1420 暂降至 1380，复测同一个页面或同一项上传，并记录结果。没有改善就恢复原值，不要同时改 DNS 与规则。
原配置中的 PersistentKeepalive = 25 表示相应的保活间隔为 25 秒，不是超时时间或重试次数。是否需要保活取决于网络与服务配置；它不能替代正确的密钥、Endpoint 或可用的 UDP 路径。
在 Home 填写并分层验证
Home 管理连接条目，Config 管理规则配置，Settings 管理应用设置。填写 WireGuard 参数与导入规则配置是两件事：前者提供连接方式，后者决定哪些请求使用该连接。界面个别字段的展开方式可能随当前应用界面变化，标准配置字段与界面字段应按含义对应，不按列表位置机械粘贴。
-
准备原配置
保留用户已有服务提供的原始配置，核对 Interface 与 Peer 是否属于同一台设备。先记录原来的 Global Routing 状态，便于测试后恢复。
-
选择类型
进入 Home → 右上角「+」→ Type → WireGuard。若已有条目需要修改，从 Home 进入该条目的编辑页，不必重复创建多个内容相近的条目。
-
对应参数
将 Endpoint 对应到服务器地址与 Port，将 Interface.PrivateKey 对应到 Private Key，将 Peer.PublicKey 对应到 Public Key。Address、Preshared Key 与 MTU 按原配置和编辑页实际字段逐项核对后保存。
-
隔离规则
回到 Home 选中保存的 WireGuard 条目，临时使用 Global Routing → Proxy，开启连接后测试一个已知可访问的 HTTPS 页面。这样可先减少 Config 规则带来的干扰，但仍需检查 DNS 与其他生效设置。
-
恢复日常设置
基础访问通过后恢复原来的 Global Routing，再重复测试同一目标。如启用了 Settings → On Demand，排查期间可暂时关闭自动触发，避免手动断开后又连接；测试完成后按原状态恢复。
连接开关处于开启状态，只能说明本机连接流程已启动，不能单独证明远端已经完成 WireGuard 握手。延迟测试有数值也不能代替网页访问验证：测试目标、测试方式与实际请求路径可能不同。应同时观察域名解析结果、目标访问结果及可用的连接记录。
Global Routing 如何影响验证结果
以下只比较 Shadowrocket 内的三种分流姿态，便于解释测试差异；Global Routing 还可能显示 Scene，本文不以它作为隔离测试的基线。推荐的 Config 指日常按已核对规则使用，并不表示任意配置文件都能直接适用。
Config
推荐按当前 Config 的规则与策略处理请求。先匹配的规则先决定结果，因此 WireGuard 条目可用，不等于每个域名都会使用它。
适合:基础连接已验证后的日常规则分流
Proxy
以代理姿态处理流量，可用于临时减少普通分流规则的影响。测试前确认当前选中的连接确实是待检查的 WireGuard 条目。
适合:初次填写参数后的短时隔离测试
Direct
以直接连接方式访问目标。此时网页可以打开，并不能证明 WireGuard 参数正确，应与 Proxy 下访问同一目标的结果区分记录。
适合:对照当前网络的直接访问情况
回到 Config 后，如果只有部分目标失败，检查规则顺序以及对应策略的实际选择。DOMAIN-SUFFIX 按域名后缀匹配，IP-CIDR 按 IP 网段匹配，GEOIP 按 IP 地理数据库匹配，FINAL 为未命中前面规则的请求提供最终动作。不要通过反复更换 Private Key 来处理一个只在 Config 下发生的规则匹配问题。
常见填写问题与排查顺序
Private Key 填完了，为什么仍然连不上？
回到 Home 中该条目的编辑页，依次核对 Type、Endpoint 地址、Port、Private Key 与对端 Public Key。随后确认远端登记的是该私钥对应的本机公钥；若提供了 Preshared Key，两端也必须一致。只检查私钥字符数不够。
Address 能不能直接填服务器 IP？
不能按这一思路替换。Address 是服务端分配的隧道内本机地址，服务器公网地址属于 Endpoint。对照原配置的 Interface.Address 恢复，并保留前缀长度；没有取得 Address 时，先向已有服务的管理方确认。
Wi-Fi 正常，换蜂窝网络就失败怎么办？
先在两个网络下使用同一条目、同一 Global Routing 与同一测试目标，排除测试条件变化。再核对 Endpoint 的 IPv4/IPv6 可达性和 UDP 路径。如果问题只在空闲后出现，检查原配置的 PersistentKeepalive；若大请求才失败，再单独验证 MTU。
订阅更新之后，手动修改为什么消失了？
订阅管理的条目可能在更新时重新写入参数。先确认正在编辑的是手动条目还是订阅生成的条目，记录被覆盖的字段，并核对订阅源返回的配置。长期修正应与已有服务提供的源配置保持一致，不要在每次刷新后盲目重复修改。
把 MTU 调低就能解决所有加载问题吗？
不能。先确认 Proxy 下能否访问目标，再检查解析是否成功；只有可重复的大报文相关现象才支持继续测试 MTU。密钥不匹配、端口错误或 DNS 不可达，都不会因为降低 MTU 而自动修复。
完成排查后，记录实际使用的网络、Global Routing、测试目标、改动项与结果。向已有服务的管理方反馈时，可描述“同一目标在 Proxy 下失败、Direct 下正常”或“小请求成功、上传停滞”等现象，但应遮盖密钥与个人配置。明确的对照记录比公开整份配置更有助于定位问题。