Loon 插件能看到明文密码：MITM 排查-TKMiss Notes

先说结论：开启 Loon 的 MitM，不等于“所有 App 的所有密码都会自动可见”。本文所说的“插件”仅指处理请求、响应的第三方 JavaScript 脚本或复写模块。Loon 官方能力页明确支持解密 HTTPS 和 HTTP/2 请求与响应，并交给脚本处理；因此，在流量经过 Loon、证书被系统信任、目标命中 MitM 规则且脚本实际读取内容时，相关密码字段才可能以明文出现。

如果已经在真实账号里看到密码，先止损：在 Loon 配置编辑页停用 MitM、脚本和复写，并回退可疑插件。iOS 可按资料中的路径，在“设置 → 通用 → 关于本机 → 证书信任设置”关闭 Loon 证书信任；证书的安装入口是“设置 → 通用 → VPN 与设备管理”，具体入口以当前版本为准。随后在可信设备上修改密码，范围包括该账号及复用密码的账号，并撤销旧会话和令牌。需要继续排查时，只用测试账号和唯一测试标记，不再拿真实密码重试。

开了 MitM，为什么密码会变成明文？

关键不在“开了开关”，而在这些条件同时成立：Loon 实际接管流量，目标域名命中 MitM 规则，根证书被系统信任，且没有被应用的证书锁定机制拦截；请求或响应随后被脚本读取，或被记录到请求记录中；最后，密码字段本身可读。HTTP 没有 TLS 层，查看请求参数或表单时，内容本来就可能直接可见。

URL 参数、表单、JSON 和 Header 中的密码可能按原样出现；一次性令牌、哈希或应用层自定义密文则不会因为 MITM 自动变成明文。MITM 解决的是传输层加密，不会自动破解应用层方案，但可重放的令牌仍可能等同有效凭据。

为什么我这里只有报错、空白或仍是密文？

排查时，用唯一测试标记做三段对照：先关闭 MitM 和脚本，确认目标请求正常；再只开启 MitM 并查看请求记录，观察是否出现 TLS 警告、连接失败或仍然只有密文；最后逐个加入脚本，检查脚本任务是否有记录。

如果开启 MitM 后出现 TLS 错误，优先检查证书是否安装并受信任；如果连接正常却没有目标记录，检查目标匹配和流量路径；如果请求已经可读而脚本仍为空白，检查脚本是否执行、是否命中目标；如果只在加入脚本后连接失败，还要考虑脚本错误或应用的证书锁定。Loon 没有统一的“某错误码对应某原因”，不同版本下同一报错也不能直接套用结论，只能在目标版本上验证。

解密后的内容由谁处理，是否已经外传？

Loon 处于解密链路中，第三方脚本也能处理解密后的请求与响应，但“具备可见条件”不等于“已经上传”。先把配置回退到没有第三方脚本的最小状态，再逐个启用并审阅代码：是否读取请求体或 Header，是否保存日志，是否包含向外部发起请求的逻辑。没有脚本执行、持久化记录或出站证据时，不能断言密码已经外泄。近期 V2EX 与 Clash by Clash 的讨论也涉及这类脚本的信任边界，但不能替代对具体脚本的审计。