本文面向已经持有自己服务配置的用户：先分清设备自身与远端 Peer 的参数，再按来源填写 WireGuard 字段，最后用“能否握手、能否传输、能否打开目标地址”三个层次定位问题。文中的地址与端口仅用于说明格式，不是可用的连接信息。
填写前：把两端的资料分开
WireGuard 的配置描述的是一条设备与远端 Peer 之间的加密隧道。Shadowrocket 是 Apple 平台上的付费客户端，iPhone、iPad 用户从 App Store 获取；系统要求以 App Store 页面标注为准。购买客户端并不会产生可用的远端服务。开始填写之前，应先从自己已有的服务管理页面或管理员处取得专用于这台设备的配置资料。
最容易混淆的是两个方向的密钥：PrivateKey 属于本机设备，必须由设备使用并妥善保管；要填入远端 Peer 的 PublicKey，则由远端提供。远端还需要知道与本机 PrivateKey 对应的设备公钥，才能识别这个 Peer。不要把远端公钥复制进本机私钥栏，也不要以为两栏填写同一段字符就能建立连接。
按角色核对配置来源
本机设备
PrivateKey：这台设备使用的私钥，不作为公开资料传递。Address：分配给这台设备的隧道内地址，通常带有前缀长度。DNS：如服务配置指定了解析服务器，按其说明填写。
远端 Peer
PublicKey：远端的公钥，不是本机公钥。Endpoint：远端可访问的主机名或 IP 地址及 UDP 端口。AllowedIPs：哪些目标地址可以交给该 Peer，由服务配置决定。
结论：按“本机”与“远端”两列逐项对照原始资料；缺少关键字段时，先向配置提供方核对，不靠猜测补值。
如果已有一份标准 WireGuard 配置文本，可以先辨认 [Interface] 与 [Peer]：前者通常列出本机参数，后者通常列出远端参数。界面里的字段布局可能与文本分组不同，但参数归属不会因为展示位置而改变。不要把整段文本当作一个字段粘贴到 PrivateKey 或 Endpoint 中。
PrivateKey、PublicKey、Endpoint、MTU 分别管什么
PrivateKey 用于本机参与 WireGuard 握手，对应的公钥需要登记在远端配置中。它是敏感凭据：排查时可以确认是否填错位置、是否混用了另一台设备的资料，但不应在截图或公开求助内容中展示原文。更换这把私钥后，对应的本机公钥也会变化，远端原有登记需要同步调整。
PublicKey 指向要连接的远端 Peer；填错时，即使主机名和端口正确，双方也不能凭错误的身份信息完成有效握手。Endpoint 则是寻找远端的入口，常见写法为“主机名:端口”，例如仅作格式演示的 vpn.example.com:51820。其中 51820 只是示例 UDP 端口，实际值以自己的服务配置为准。
MTU 限制隧道内单个数据包的大小。值过大时，某些网络路径可能出现小请求正常、大页面或文件传输停顿的现象；值过小则增加传输开销。1420 是常见的尝试起点，不代表所有网络都应填写这个数。先采用配置提供方给出的值；只有在确认已握手、且问题集中于大数据包传输时，才按其指导逐步调整并记录调整前后的结果。
在 Add Server 中按来源录入
手动填写适合已经拿到 WireGuard 专用参数、且希望逐项检查的人。若现有服务只提供订阅 URL，应先确认订阅中是否包含可用的 WireGuard 配置；订阅链接本身不是 Endpoint，不能把整条 URL 填进远端地址栏。下面的路径用于手动添加，实际字段显示以当前应用内界面为准。
打开添加页
进入 Shadowrocket 的
Home，点右上角+打开Add Server；在Type中选择WireGuard。填写本机项
对照已有配置填写
PrivateKey与分配给本机的Address；如配置明确给出DNS，再填写该值。不要将示例地址当作实际分配地址。填写远端项
将远端
PublicKey、Endpoint和AllowedIPs分别放进对应字段。若配置包含PresharedKey，按原始资料填写；没有提供时不要自行编造。核对 MTU
优先使用配置资料给出的
MTU。资料未指定时，先保留界面允许的默认设置，避免在首次连接前同时改动多个参数。保存并测试
保存后回到
Home，选中刚添加的条目并开启连接。首次启用时，按系统提示允许添加 VPN 配置；随后观察连接状态并进行实际访问测试。
AllowedIPs 尤其值得与原始配置逐字符核对。它表示该 Peer 接收哪些目标地址；0.0.0.0/0 表示整个 IPv4 地址空间，::/0 表示整个 IPv6 地址空间，但是否应使用这些范围取决于已有服务配置。它与 Shadowrocket 的 Global Routing 不是同一个设置：前者约束 WireGuard Peer 的目标范围，后者决定应用如何按当前姿态处理请求。
握手失败：按地址、身份、通路的顺序查
“开关已打开”与“WireGuard 已完成握手”不是同一件事。先确认所选的是刚保存的 WireGuard 条目，再检查是否有来自远端的实际响应。若现有管理界面或服务方诊断信息提供最近握手时间，可以用它辅助判断；界面没有显示该指标时，不应仅凭开关颜色推定握手成功。
一直没有握手，先看哪里？
先核对 Endpoint 的主机名、冒号及 UDP 端口，确认填的是现有服务给出的入口。切换到另一种可用网络再试一次；若仅某个网络失败，优先检查该网络能否到达对应的 UDP 入口。
地址没填错，为什么仍失败？
逐项比对远端 PublicKey、本机 PrivateKey 及可选的 PresharedKey。请配置提供方确认远端已登记这台设备对应的公钥，并检查设备的 Address 是否与远端记录一致。
换网后偶尔恢复，怎么定位？
记录失败发生在哪种网络，以及同一配置在另一种网络下是否能握手。若服务配置指定了 PersistentKeepalive，核对其值是否完整录入；这个设置可帮助某些经过地址转换的连接维持映射，但不能修复错误的密钥或端口。
握手有了，网页仍加载不全？
先用小请求与较大页面分别测试，再核对 AllowedIPs、DNS 和 Global Routing。如果主要是较大传输停顿，记录现有 MTU 后再逐步试调；每次只改一个设置。
排查的关键是保留对照：同一个配置、同一目标地址，只改变一项设置或一种网络条件。若同时更换密钥、端口、路由姿态与 MTU，即使恢复访问，也无法判断真正的原因。向自己的配置提供方反馈时，说明错误发生的步骤、网络类型与测试现象即可，切勿附上 PrivateKey 原文。
握手成功后，区分分流问题与传输问题
成功握手只能说明两端完成了必要的协商，不能单独证明每个目标地址都会经由隧道、DNS 一定按预期解析，或目标服务必然可用。先在 Home 使用 Connectivity Test 辅助观察，再用明确的目标地址复测。若仅特定目标失败，应核对该目标是否落入 AllowedIPs，以及当前 Global Routing 是否将请求交给所选连接。
Config
推荐按配置中的规则决定请求去向。排查单个目标时，检查该目标命中的规则及最终动作；不能仅凭 WireGuard 已握手判断规则结果。
适合：日常按规则使用，并逐条检查分流结果。
Proxy
临时将请求交给选中的代理连接，可用于判断问题是否出在当前规则路径；测试前仍须确认 WireGuard 配置本身已能连接。
适合：短时间对照规则分流与连接本身。
Direct
请求走直连。若停留在此姿态，目标访问结果不能作为 WireGuard 传输正常与否的依据。
适合：建立直连对照，测试完成后再核对所需姿态。
使用 Config 时，规则关键字如 DOMAIN-SUFFIX、GEOIP、IP-CIDR 与 FINAL 分别涉及域名后缀、地理位置、IP 网段及兜底匹配。先确认测试目标命中了什么规则，再判断是否需要检查 WireGuard。若所有目标都无法传输，优先回查 Peer 参数；若只有部分域名失败，优先比较 DNS 结果、规则命中与目标地址范围。
完成测试后，把临时改动过的 Global Routing、MTU 或 DNS 设置恢复到经过验证的值，并保存一份不含私钥明文的故障记录。这样下次遇到“能握手但不能访问”的情况，可以先对照网络、目标与设置变化，而不必重新猜测每个字段的用途。