代理终端和二级代理：脚本进程抓包与代理链配置

两类「代理」问题经常被混淆：一类是流量怎么进 Reqable（代理终端解决），一类是流量进来后怎么出（二级代理解决）。

代理终端：让脚本进程走代理

浏览器和大部分桌面应用会遵循系统代理，但 Python、NodeJS、Ruby 等脚本进程经常无视系统代理——命令行里跑的 requests、axios 请求不会出现在调试列表里。

代理终端功能就是为此设计的：在 Reqable 内置的终端环境里执行你的 Python/Node 程序，进程的流量会被自动引导进 Reqable 的代理服务器，从而出现在调试列表中。

它同时也是 SSL 问题的解药之一：Python requests、Node 网络库报「无法验证证书」时（因为它们不读系统证书库），在代理终端里执行可以正常建立连接（见 SSL 握手失败六大原因 的第 5、6 条）。

另一个相关场景：目标应用支持手动配置代理的话，直接把代理地址指向 Reqable（127.0.0.1:端口）即可，不必动用代理终端；实在不行还可以用 Proxifier 类第三方工具强制代理。

二级代理：把流量再转一手

二级代理是 Reqable 作为代理客户端的「上游」配置：所有经过 Reqable 的流量再转发给另一个代理服务器出去。典型用途：

• 需要通过公司网关/内网代理才能上网的环境；
• 配合其他代理工具实现链式转发（官方 FAQ 对相关场景的说明见 抓不到流量怎么办）。

配置入口在「代理」菜单中。启用二级代理后注意两点：

• 它与「抓不到流量」的排查有关：误开二级代理会导致本机应用流量抓不到（排查清单第 3 条）；
• 社区版二级代理数量上限为 1 个。

反向代理

同族还有一个「反向代理」功能：把 Reqable 暴露为一个服务器入口，把收到的请求转发给指定后端，适合模拟网关转发类场景。社区版可建 3 个反向代理规则，细节以官方文档为准。

三者的记忆锚点：代理终端管进、二级代理管出、反向代理管服务器视角的转发。