Shadowrocket MitM抓包与URL重写实战：HTTPS解密配置全解析

MitM 能做什么：先确认适用范围

MitM 是中间人代理处理流程的简称。在 Shadowrocket 中启用相关功能后，应用可对符合条件的 HTTPS 请求进行解密处理，让用户检查请求信息，并按配置应用 URL Rewrite 等处理。它不是“查看任意网站内容”的开关：请求还必须经过 Shadowrocket，目标主机需要纳入 MitM 范围，设备也必须信任相应证书。任何一项不满足，都可能只能看到连接信息，无法读取 HTTPS 请求内容。

请只对自己拥有或已获明确授权检查的域名使用 MitM。解密过程中，请求路径、查询参数、请求头和响应内容可能包含账号标识、会话令牌、个人资料等敏感信息。不要为方便排错而将范围设成所有主机，也不要把包含真实凭据的抓包结果直接分享。

开始前记下当前的配置文件、Global Routing 选项和连接状态。按规则分流时，进入 Home → Global Routing 选择 Config，并确认正在使用的配置文件确实包含本次测试规则。不要同时更换连接、配置和网络，否则测试结果很难归因。

生成证书、安装并开启系统信任

HTTPS 解密需要设备信任 Shadowrocket 使用的 CA 证书。生成证书、安装描述文件和开启完整信任是三个不同步骤：仅生成不等于已安装，仅安装也不一定代表系统已允许该根证书用于 TLS 信任。菜单显示可能随系统版本变化；如果某个入口名称不同，以设备当前显示为准，不要跳过信任状态核对。

1. 备份当前配置

   进入 Config，记录当前选中的配置，并保留原有内容。后续仅修改 MitM 和 URL Rewrite 相关字段，避免覆盖已有的 DNS、Rule 或其他设置。

2. 生成 CA 证书

   在 Shadowrocket 的 Settings → Certificate 中查找生成或安装 CA 证书的入口，按应用提示生成证书。只在自己的测试设备上进行，避免将证书文件或相关私钥材料发送给他人。

3. 安装证书描述文件

   按 Shadowrocket 的提示打开系统设置并完成描述文件安装。若系统要求确认安装或设备身份验证，先核对描述文件来源确为刚才的 Shadowrocket 操作，再按提示继续。

4. 开启完整信任

   在系统 Settings → General → About → Certificate Trust Settings 中检查对应根证书的信任开关。确认后返回 Shadowrocket，再对限定的测试主机启用 MitM。

5. 测试后清理

   完成检查后关闭不再需要的 MitM 主机规则；若以后不再使用该证书，可在系统证书信任设置中撤销信任，并按系统提供的方式移除对应描述文件。

不同系统版本的描述文件安装入口可能有所差异。证书安装后仍出现 TLS 信任错误时，先确认系统的完整信任开关是否开启、设备日期与时间是否正确，以及 Shadowrocket 当前是否使用生成证书对应的配置。不要通过关闭目标应用的安全校验来绕过问题。

限定主机名：只解密需要检查的目标

MitM 主机名范围决定哪些 HTTPS 目标可以进入解密处理。应使用具体、最小化的主机名，而不是宽泛通配范围。访问一个网页时，页面还可能请求独立的 API、图片或登录主机；如果确实需要检查这些请求，应逐个确认它们属于授权范围，再分别添加。不要因为某个页面显示不完整，就直接把范围扩大到全部域名。

在配置文件的 [MITM] 段中，常见配置项包括启用状态和主机名列表。下面是结构示例，域名仅用于说明格式；修改时要合并到现有配置中，不要重复建立同名段：

[MITM]
enable = true
hostname = example.com,api.example.com

example.com 与 api.example.com 是两个明确列出的目标。请依照 Shadowrocket 当前配置界面支持的主机名格式填写；不要把完整 URL、路径或查询参数放进 hostname 字段。若已有 [MITM] 段，应编辑原段，并检查配置中的条目是否与实际请求的主机名相符。

主机名是否进入 MitM 处理范围，与请求是否实际经过当前配置也是两回事。确认 Home → Global Routing → Config、当前配置文件、连接状态和目标域名后，再发送一条新的测试请求。已经打开的网页可能复用缓存或现存连接，未必能代表修改后的规则效果。

编写 URL Rewrite：匹配地址并调整目标

URL Rewrite 规则用于匹配请求 URL，并按规则指定新的目标地址或处理方式。它与 [Rule] 中的 DOMAIN 分流规则用途不同：分流规则决定请求采用什么策略，URL Rewrite 则针对符合条件的 URL 执行改写。处理 HTTPS 请求时，仍需满足证书信任、MitM 启用和主机名范围等前提。

以下示例把自有测试站点中的旧路径改写到新路径。域名和路径是占位示例，不是可用服务地址；使用前应将其替换为自己有权测试的地址，并根据 Shadowrocket 当前支持的规则格式核对正则表达式与处理类型。

[URL Rewrite]
^https://example\.com/legacy/(.*)$ https://example.com/current/$1 302

这条规则的意图是匹配 https://example.com/legacy/ 下的请求，并把捕获到的后续路径带入新地址，最后使用 302 类型处理。实际配置时要确认匹配表达式、替换地址和类型字段的位置符合当前编辑界面的要求。正则中的点号通常需要转义，路径边界也应写清楚，避免意外匹配到相似但无关的 URL。

规则顺序也值得检查：若较宽泛的表达式排在前面，它可能先匹配请求，使后续更具体的规则没有机会生效。建议一次只添加一条规则，用唯一、易识别的测试路径验证；确认行为后再增加其他规则。不要用真实登录、支付或个人资料页面作为首次测试目标。

验证抓包结果，并定位规则未生效的原因

验证时要发送新的请求，并同时核对目标主机、请求 URL、当前配置和 MitM 状态。只看到 VPN 已连接不能证明 HTTPS 已解密；只看到请求记录也不能证明 URL Rewrite 已按预期修改目标。测试前记录原始地址，测试后对照记录中的请求与结果，并避免把敏感字段复制到公开截图或日志中。

• 没有 HTTPS 请求详情：检查目标是否在 [MITM] 的 hostname 范围内、证书是否已安装并开启系统信任，以及应用请求是否经过 Shadowrocket。
• 提示证书错误：重新核对根证书信任状态、系统时间和当前配置使用的证书；不要忽略安全警告继续输入敏感信息。
• 请求可见但 URL 未变化：核对请求是否符合正则表达式、规则是否保存到当前生效配置，以及 MitM 是否覆盖该 HTTPS 主机。
• 部分应用仍不能解密：某些应用可能采用证书固定或其他 TLS 安全机制。此时应尊重应用的安全设计，改用自有测试环境或应用提供的诊断方式，不要尝试规避校验。
• 改写后页面异常：检查新地址是否有效、路径捕获是否正确，以及服务器是否预期接收该请求；恢复原规则后再逐项测试。

还有一种常见情况是规则已经更新，但应用继续使用旧连接或缓存内容。此时先关闭并重新发起目标请求，必要时在确认不会影响其他连接后重新连接，再检查新记录。若无法复现，应回到最小测试配置，暂时只保留一个目标主机和一条 Rewrite 规则。

常见问题