Shadowrocket WireGuard 配置填写:私钥、Peer 公钥与 MTU 参数说明

本文速览

本文适合已从自己的服务商取得 WireGuard 配置、准备在 Shadowrocket 手动填写字段的用户。先分清本机 Interface（接口）与远端 Peer（对等端），再对应私钥、公钥、隧道地址和连接端点，最后核对 MTU 与分流设置。文中的地址、域名和端口只用于解释结构，不能作为可连接的配置。

一、先分清 Interface 与 Peer 的配置归属

Shadowrocket（小火箭）中的 WireGuard 配置包含两类信息：本机用什么身份与地址参与隧道，以及本机连接哪个远端。常见的 WireGuard 文本配置用 [Interface] 和 [Peer] 分段。手动添加时，应按字段含义对应到表单，而不是按文本出现顺序逐行粘贴。

Private Key（私钥）属于本机身份；Peer 的 Public Key（公钥）用于识别远端。Address（隧道地址）是服务商分配给本机的隧道内地址，Endpoint（远端连接端点）才是网络上要访问的服务器域名或 IP 与端口。两者不能互换。

字段归属：本机 Interface 与远端 Peer

Interface（本机接口）

PrivateKey：本机私钥，对应本机身份。
Address：本机在隧道中的 IPv4 或 IPv6 地址。
MTU：隧道接口可承载的 IP 包大小参数。
DNS：若配置提供，表示配套的解析服务器信息。

Peer（远端对等端）

PublicKey：远端公钥，不是本机公钥。
Endpoint：远端主机地址与 UDP 端口。
PresharedKey：双方约定的可选预共享密钥。
AllowedIPs：该 Peer 对应的隧道路由与地址约束。

先确认字段属于哪一端，再填写内容；不要把本机公钥填进 Peer 的 Public Key。

服务商提供的资料可能是完整文本、二维码、已有订阅中的条目，或一组单独的参数。以下步骤以手动填写为主。界面可见字段随当前应用界面而定；没有单独输入项的参数，不要改填到名称近似但含义不同的字段中，应确认该配置是否适合当前导入方式。

二、在 Home 添加 WireGuard 服务器的顺序

先保留一份完整的原始配置，再开始录入。若原始资料中只有服务商后台显示的本机公钥，没有本机私钥，就还不具备完成该身份配置的全部内容；公钥不能反推出私钥。

准备原始配置

从自己的服务商处取得完整参数。逐项找出 Interface 的 PrivateKey、Address，以及 Peer 的 PublicKey、Endpoint；有 PresharedKey 时也一并保留。
选择协议

进入 Home（首页）→ 右上角“+”→ Type（类型）→ WireGuard。确认正在新建 WireGuard 条目，而不是把整份文本粘贴进普通服务器地址栏。
填写端点

将 Endpoint 的主机部分填入 Address（服务器地址）或相应主机栏，将端口填入 Port（端口）。例如虚构端点 wg.example.com:51820 应拆为 wg.example.com 与 51820，不加网页协议前缀。
填写身份

在 WireGuard 对应参数中填写本机 Private Key、远端 Public Key 和隧道地址。若出现 Preshared Key（预共享密钥），只有原始配置提供该项时才填写；不要用另一把密钥代替。
保存并验证

保存后回到 Home，选中刚创建的条目，再开启连接。记录当前 Global Routing（全局路由）的选择与测试网络，使用自己有权访问的目标验证实际请求，不能只看连接开关是否开启。

三、Private Key、Public Key 与预共享密钥

WireGuard 的私钥与公钥有固定的编码结构，通常是表示 32 字节数据的 Base64 字符串，常见长度为 44 个字符。长度看似正确，只能排除部分复制错误，不能证明密钥属于当前服务端，也不能证明两端已经完成授权。

本机私钥可生成本机公钥，服务端通常按本机公钥识别这个客户端。随意在本机重新生成私钥，会同时改变对应的公钥；如果服务端仍登记原来的公钥，连接就无法按原有身份完成握手。因此，不要把“重新生成密钥”当作通用修复步骤。

字段	应填写的内容	常见错误
`Private Key`	分配给本机身份的私钥，通常来自 Interface 段。	复制了本机公钥，或误用了另一台设备的私钥。
`Public Key`	远端 Peer 的公钥，通常来自 Peer 段。	填成本机公钥，或把整个 `PublicKey =` 前缀一起粘贴。
`Preshared Key`	原始配置约定的额外对称密钥；两端必须一致。	原配置没有此项却自行生成，或以登录密码代替。

复制时应只取等号右侧的值，去除首尾空格和换行，但保留密钥自身的字符，尤其是可能位于结尾的 =。不要把编码中的 + 当作空格，也不要手动调整大小写。密钥不是用户名、登录密码或订阅链接。

Private Key 与 Preshared Key 应按敏感凭据保存，不放入公开截图或故障反馈正文。
反馈问题时可提供字段名称、错误表现和脱敏后的地址类型，不需要提供完整私钥。
若私钥已泄露，应让服务商撤销旧身份并重新分配，单纯修改条目名称没有安全作用。

四、Address、Endpoint 与 DNS 的填写边界

Interface 的 Address 通常带有 CIDR（地址前缀）长度，例如虚构值 10.66.0.2/32。其中 /32 表示一个 IPv4 主机地址；IPv6 单地址常见 /128。这不是端口，也不是服务器的公网地址。若界面将地址与前缀拆开输入，应分别对应，不要把斜杠后的数字填进 Port。

本机侧虚构样例

Address: 10.66.0.2/32
IPv6 Address: fd42:66::2/128
DNS: 10.66.0.1
MTU: 1420，仅作参数示意

这些数值仅说明本机字段结构，不能据此推断你的服务商分配方案。

远端侧虚构样例

Endpoint: wg.example.com:51820
Host: wg.example.com
Port: 51820，UDP 端口
IPv6 Endpoint: [2001:db8::10]:51820

完整 IPv6 端点以方括号区分主机与端口；分栏填写时按界面格式输入。

WireGuard 使用 UDP 传输。51820 是常见示例端口，并不是所有服务都使用它；实际端口必须来自你的原始配置。若当前网络无法到达该 UDP 端口，把数字改成 443 并不会自动变成可用连接，除非远端确实在相应端口提供服务。

DNS（域名解析）还需区分两个阶段：Endpoint 为域名时，建立隧道前要能解析它；隧道内的域名请求则受 Shadowrocket 当前 DNS 与配置设置影响。原始 WireGuard 文本的 DNS 是配套解析信息，不应假定手动建立一个服务器条目后，整份文本的 DNS 行就已经自动应用。

Endpoint 解析失败时，先确认域名拼写、当前网络解析和服务商给出的主机是否有效。
指定隧道内 DNS 地址时，先确认隧道可用且该地址可经隧道到达。
若使用 IPv6 地址，确认当前配置和远端都提供相应支持；填写 IPv6 地址本身不能补齐远端能力。

五、MTU 的含义与调整顺序

MTU（最大传输单元）决定隧道接口能承载的 IP 包大小。WireGuard 封装会增加额外开销，因此隧道 MTU 通常小于底层链路 MTU。在底层 MTU 为 1500 的常见情形下，外层 IPv4 封装约占 60 字节，外层 IPv6 约占 80 字节；1420 是常见取值之一，但不能覆盖所有网络路径。

MTU 过大时，可能出现小请求可用、大响应停滞、部分网页加载不完整等现象。这些只是排查线索，不是 MTU 故障的唯一证据。DNS、远端出口、UDP 丢包和规则选择也会造成相似表现，应在确认密钥与端点正确后再调整。

采用服务商指定的 MTU

以 1420 做对照

只有在需要诊断且界面允许设置时，将 1420 作为一次受控测试。它是常见隧道 MTU，不是速度档位，也不能保证适配当前路径。

适合:缺少明确 MTU、需要建立单一变量对照

临时降低到 1380

若 1420 下小请求正常而较大传输反复停滞，可临时用 1380 对照。每次保存后重建连接，并测试同一目标；没有改善就恢复原值。

适合:已排除基础配置错误后的路径排查

记录“网络类型、MTU、测试目标、成功或失败”四项即可形成有用的对照。比如在同一 Wi-Fi 下分别测试 1420 与 1380，再在蜂窝网络重复；这是一种测试方法，不是本文对某条线路的实测结果。不要把一次网页打开成功解释为最佳 MTU，也不要把单次测速高低作为唯一依据。

六、AllowedIPs 与 Global Routing 不是同一层设置

标准 WireGuard 配置中的 AllowedIPs（允许的 IP 范围）用于 Peer 的隧道路由选择，并约束从该 Peer 接收的源地址。例如 0.0.0.0/0 表示全部 IPv4 地址范围，::/0 表示全部 IPv6 地址范围。它不等同于 Shadowrocket 的域名规则，也不应直接粘贴到 Rule（规则）部分。

Shadowrocket 在应用层面还需要决定哪些请求交给所选服务器。即使密钥和 Endpoint 都正确，Global Routing 处于 Direct（直连）时，业务请求也不会按预期交给这个 WireGuard 条目。Config（配置）姿态则使用当前启用配置的规则，必须同时检查命中的策略最终指向哪里。

Proxy（代理）：将应用接管的请求按代理姿态处理，可用于临时区分服务器问题与分流问题；不能据此推断设备上所有系统流量都经过同一路径。
Direct（直连）：按直连姿态处理，不适合作为验证所选 WireGuard 出口是否生效的依据。
Config（配置）：按当前配置的规则选择策略；选择了 WireGuard 条目，不代表每个请求都一定命中它。
Scene（场景）：按已配置的场景使用相应路由安排；排查时先核对场景实际选择，不要只看姿态名称。

以下仅展示规则语法，不是完整可直接启用的配置。PROXY 必须对应你当前配置中实际可用的策略或策略组，且最终选择所需的 WireGuard 条目。规则自上而下匹配，先命中的规则决定处理方式。

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAIN-SUFFIX（域名后缀）匹配指定域名及其子域名；IP-CIDR（IP 网段）匹配目标地址范围；GEOIP（IP 地理分类）按 IP 数据库分类匹配；FINAL（最终策略）承接没有命中前序规则的请求。示例中的文档地址段用于说明语法，不是实际业务目标。

七、保存后仍无法使用时的核对方法

排查顺序是“字段是否完整 → 端点能否到达 → 密钥身份是否匹配 → 请求是否交给该服务器 → DNS 与 MTU”。每次只改一个变量，并保留原值。连接开关处于开启状态，只能说明本地连接功能已启动，不能单独证明远端握手成功或出口可用。

Private Key 填了，为什么还是不能用？

先回到 Home → 对应条目的编辑入口，检查是否只复制了密钥值、有无首尾空格，再确认 Peer Public Key 是远端公钥。若曾重新生成本机私钥，应让服务商确认其登记的客户端公钥是否同步更换，不要反复生成新密钥尝试。

开关已打开，但访问结果没变化？

在 Home 确认选中的是新建 WireGuard 条目，再核对 Global Routing。若使用 Config，到 Config（配置）确认当前启用文件，并检查测试目标命中的策略。可短时用 Proxy 对照，完成诊断后恢复原来的分流设置。

Wi-Fi 不通，蜂窝却可以，先改什么？

保持密钥和隧道地址不变，先对照 Endpoint 域名解析、指定 UDP 端口的可达性及网络限制。只有出现小请求成功而较大传输停滞等线索时，再对照 MTU。不要在切换网络的同时更换密钥、DNS 和端口。

同一份配置可以同时放到两台设备吗？

先确认服务商是否为每台设备分配独立身份。两台设备共用同一私钥与隧道地址并同时通信时，远端可能将同一 Peer 的回包端点切换到最近发包的设备，表现为连接互相干扰。需要并行使用时，应取得独立密钥对和地址。

完成配置后的保存清单

保留原始配置及其对应设备说明，敏感密钥放在受保护的位置。
记录服务器主机、UDP 端口、隧道地址与已验证的 MTU，不公开完整凭据。
若条目来自已有订阅，先确认更新是否会覆盖手动修改；不要把临时诊断值当成服务商的新参数。
测试结束后恢复原来的 Global Routing 与 On Demand 设置，并再次验证日常访问。

Shadowrocket 是 Apple 平台的闭源商业应用，主要用于 iPhone 与 iPad，唯一获取入口是 App Store，系统要求以 App Store 页面标注为准。客户端买断 ≠ 线路套餐。本文以用户已有自己的服务商与配置为前提，应用购买本身不会补齐 Private Key、Peer 公钥或远端服务参数。