2026-09-09 · 协议科普 · 约 10 分钟

Shadowrocket WireGuard 配置参数详解:PrivateKey、PublicKey、Address 与 MTU

说明在 Shadowrocket 中添加 WireGuard 类型节点时各字段的含义与填写来源,以及 MTU、DNS、保活间隔对 iOS 连接稳定性的影响。

本文速览

配置 WireGuard，先区分本机身份、对端身份与外层连接地址，再检查隧道内 Address。本文适合已经持有自己服务商所提供配置的用户：按字段对应关系完成录入，以默认 MTU 建立基线，再分别验证 DNS、UDP 可达性与空闲后的恢复行为，避免把所有连接问题都归因于密钥或 MTU。

先分清密钥、隧道地址与 Endpoint

在 Shadowrocket（小火箭）中选择 WireGuard 类型，并不等于已经建立可用连接。WireGuard 使用密钥识别通信双方，通过 UDP 传输封装后的数据；服务端还需要登记客户端对应的 PublicKey，并允许其使用分配的隧道地址。只有客户端一侧填得完整，不能替代服务端的配对配置。

本文用 [Interface]、[Peer] 中的标准 WireGuard 字段解释含义。这些是配置文件里的名称，不表示 Shadowrocket 编辑页一定按相同分组或拼写排列。录入时应对照应用实际显示的字段，尤其不能仅凭一个 Address 标签判断它是服务器地址还是隧道内地址。

32 字节
WireGuard 原始密钥长度；常见文本表示为 Base64
UDP
Endpoint 的传输协议，端口由实际配置指定
2 类地址
外层 Endpoint 与隧道内 Address，不能互换

例如，192.0.2.10:51820 可以用于说明 Endpoint 的“主机地址加端口”结构，10.66.0.2/32 可以用于说明隧道内 IPv4 地址的结构。前者使用文档示例地址，二者都不是本文提供的连接参数；实际值必须来自用户已有配置。端口 51820 是常见示例，不是所有 WireGuard 服务都固定使用的端口。

PrivateKey 与 PublicKey 的填写来源

PrivateKey 是当前客户端身份的私钥；与它配对的客户端 PublicKey 应登记在服务端。客户端的 [Peer] 中所需的 PublicKey，则是服务端公钥。这两个方向最容易混淆：把自己的公钥填入对端公钥栏，即使格式有效，也不能完成预期的身份验证。

本机身份与地址

PrivateKey
来自当前客户端配置的私钥，必须保密。
客户端 PublicKey
由本机 PrivateKey 对应得到，供服务端登记。
Address
服务端分配的隧道内地址，例如 10.66.0.2/32。

本机私钥、服务端登记的客户端公钥与分配地址需要相互对应。

对端连接信息

PublicKey
对端服务器公钥，不是客户端自己的公钥。
Endpoint
服务器主机名或 IP 地址，以及实际 UDP 端口。
PresharedKey
可选的预共享密钥；仅在原配置要求时填写。

PresharedKey 不能用 PrivateKey 或 PublicKey 代替，也不能自行补一个值。

WireGuard 常见 Base64 密钥文本为 44 个字符，通常带末尾的 =。这只能作为录入时的格式检查，不能证明密钥属于正确的对端。复制时检查有无多余空格、换行或引号；不要为了凑长度自行增删字符。若密钥已泄露，应更换相应密钥并同步服务端登记，而不只是修改节点备注。

在 Home 添加 WireGuard 的核对步骤

先保留当前可用配置，再新增一个用于核对的条目。以下步骤以手动录入为主；如果参数由已有订阅导入，应先确认它实际生成的是 WireGuard 类型。不要把 WireGuard 配置文本粘贴进仅接收订阅 URL 的输入栏，也不要假定所有配置格式都能通过同一个导入入口识别。

  1. 选择类型

    进入 Home → 右上角“+”→ Type → WireGuard。确认类型后再填写参数，避免在其他协议的编辑表单中套用同名字段。

  2. 填写对端

    把原配置 Endpoint 中的主机与端口对应填入服务器地址和端口字段。例如 192.0.2.10:51820 表示主机为 192.0.2.10、UDP 端口为 51820；这里仅演示拆分方法。

  3. 对应身份

    填入本机 PrivateKey、对端 PublicKey，以及原配置要求的 PresharedKey。逐项确认来源，不交换客户端公钥与服务器公钥。

  4. 核对地址

    将分配的隧道内 Address 对应到本地地址字段。原配置若同时包含 IPv4 与 IPv6，应分别核对；界面把地址与前缀分开时，按实际字段填写。

  5. 保存验证

    保存后返回 Home，选中该条目，再核对 Global Routing。首次连接按系统提示完成 VPN 配置授权，随后用实际请求验证，不只看连接开关。

订阅管理的条目可能在下一次更新时被来源配置重新写入。要做 MTU 或保活间隔实验，应先记录原值并使用可独立保留的测试条目；如果修改随后消失，先检查是否发生了订阅更新，而不是反复重填密钥。Shadowrocket 的 Home、Config、Settings 分别承载连接选择、配置管理和应用设置，修改某个节点并不自动改变当前选中的 Config。

Address、AllowedIPs 与分流规则的边界

Address 表示隧道接口的本地地址，不是 DNS 地址，也不是服务端公网 IP。后缀 /32 表示一个 IPv4 主机地址，/128 表示一个 IPv6 主机地址。不要把服务商分配的地址随意改成另一台设备的地址；重复使用同一身份或地址可能造成回包位置变化与间歇中断。

配置项具体含义不能据此推断
Address本地隧道地址，例如 10.66.0.2/32不能作为公网服务器地址使用
Endpoint外层 UDP 数据发送到的主机与端口端口开放不等于身份配对成功
AllowedIPs标准 WireGuard 的对端地址选择及接收来源约束不能直接等同于 Shadowrocket 的域名分流规则
Global RoutingShadowrocket 当前的全局路由姿态选中 WireGuard 条目不代表所有请求都使用它

在标准 WireGuard 配置中，0.0.0.0/0 和 ::/0 分别覆盖全部 IPv4 与 IPv6 地址范围。但将 WireGuard 作为 Shadowrocket 节点使用时，实际请求是否进入这个节点，还要核对 Global Routing、当前 Config 与命中的策略。不要仅凭原文件包含这两个范围就判断应用内所有流量都会使用该节点。

MTU：先保留基线，再处理大包异常

MTU 是隧道接口允许承载的最大 IP 包大小，不是网速上限。WireGuard 封装还需要外层 IP、UDP 与协议开销；如果底层路径可容纳的数据包更小，而路径 MTU 探测没有正常工作，就可能出现小请求成功、较大响应停住的现象。握手正常但页面资源加载不完整，才是值得进一步检查 MTU 的线索之一，不能据此直接认定原因。

保留默认或原配置

推荐

首次测试沿用应用默认处理或已有配置明确指定的 MTU，先确认密钥、地址与 Endpoint 能正常工作。这样得到的结果可以作为后续比较的基线。

适合:初次录入、连接正常、尚未发现大包异常

单变量降低 MTU

仅在原值高于目标值时，尝试较小值，例如从 1420 改为 1380，再用同一请求复测。两者是排查示例，不是通用最优值；每次只改 MTU，并保留恢复记录。

适合:小请求成功，但大响应或特定网络下反复停顿

恢复原值复核

若调小后故障没有变化，恢复原值，转查 UDP 可达性、DNS 和服务端路由。较小 MTU 可能增加包数量，持续调低并不能解决所有问题。

适合:调整无效，或现象实际由其他参数引起

对需要承载 IPv6 的隧道，不要随意把接口 MTU 调到 1280 以下；1280 是 IPv6 最小链路 MTU 的重要边界。排查期间应保持其他条件一致，例如使用同一个 Wi-Fi、同一目标请求，并记录修改前后现象。本文数值用于解释测试方法，不代表对某条线路的实测结果或性能保证。

DNS 与 PersistentKeepalive 分别解决什么问题

DNS 负责把域名解析为地址；WireGuard 的加密握手并不会自动证明域名解析可用。若 Endpoint 使用主机名，建立外层连接之前也需要解析该主机名。这里要区分“无法解析服务器主机名”与“隧道建立后无法解析访问目标”两个阶段，它们涉及的查询路径可能不同。

标准 WireGuard 配置中的 DNS 是配置工具使用的辅助设置，不是 WireGuard 握手协议本身的一部分。把节点用于 Shadowrocket 时，不应假定原文件的 DNS 行一定完整接管应用的解析行为；还应核对当前 Config 的 DNS 设置。若 DNS 地址只能从隧道内访问，则必须先具备通向它的正确路径。

PersistentKeepalive 的单位是秒，用于在空闲时发送保活数据以维持 NAT 或防火墙映射。25 秒是常见参考间隔，并非必须值；标准配置中 0 表示关闭周期保活。更短的间隔会增加空闲时的网络活动，并不等于更稳定，应按已有配置和网络现象决定。

按失败阶段检查，而不是同时修改参数

Home 显示连接已开启，首先说明系统 VPN 通道已启动，不能单独证明 WireGuard 对端已回应。延迟测试也需要结合测试方式理解：一次超时并不能区分“UDP 不可达”“密钥不匹配”与“测试目标无响应”。应把错误定位到建立连接、传输数据、解析域名或空闲恢复中的具体阶段。

观察现象优先核对下一步操作
始终没有有效响应Endpoint、UDP 端口、双方公钥配对、PresharedKey在 Wi-Fi 与蜂窝网络分别测试，并核对服务端登记
有回应但目标不可达隧道 Address、服务端转发、当前选中节点与策略确认请求确实进入该节点，再检查服务端路由
仅域名访问失败Endpoint 解析与目标域名解析所处的阶段在相同路由条件下比较解析结果和已知 IP 的可达性
小响应正常、大响应停住路径 MTU、IPv6 路径及中间网络限制只调整 MTU，重复同一测试并记录结果
空闲一段时间后失效NAT 映射、PersistentKeepalive、网络切换记录空闲时长，按原配置调整保活后复测

如果怀疑规则绕过了测试节点，可在 Home → Global Routing 暂时选择 Proxy，并确认选中的是待测 WireGuard 条目。此举用于减少规则分流带来的变量，不会修复节点本身。测试结束后恢复原来的 Config 或其他既有姿态，避免把诊断设置误留为日常设置。

把 WireGuard 改成 443 端口会更容易连接吗？

只有对端实际监听相应 UDP 端口时才能这样改。UDP 443 与 TCP 443 是不同的传输端点；某个网页能通过 TCP 443 打开，不证明当前网络允许到同一地址的 UDP 443。不要通过猜测端口替代对原配置的核对。

同一套 WireGuard 参数能直接复制到 iPhone 和 iPad 吗？

不要默认两台设备可同时复用同一身份与隧道地址。对端可能根据最近收到的有效报文更新通信端点，复用配置可能导致两端互相影响。应使用已有服务商明确分配给各设备的身份和地址；应用购买适用性与协议身份分配是两回事。

完成排查后，保留一份不含密钥的变更记录：修改了哪个字段、原值与新值、使用哪种网络、哪个请求恢复正常。若所有网络都无法收到有效回应，应回到 Endpoint 与身份配对检查；若仅一类请求异常，再检查 DNS、分流和 MTU。这个顺序比同时修改多个参数更容易得到可复现的结论。

App Store 正版核验查看购买与设备说明