在配置Shadowrocket多层代理时，用户首先在主界面选择作为最终出口的落地代理节点并确认其单层模式下能够正常访问目标网站，然后进入设置页面找到“通过代理”选项，将前置跳板的IP地址、端口、SOCKS5或HTTP协议类型以及认证凭据逐项正确填入，确认无误后将开关开启并立即访问IP检测网站验证当前出口是否为落地代理地址。验证通过后链路即生效，但需特别注意该配置仅支持两层结构且UDP流量在链式转发中无法正常工作，游戏和语音通话等依赖UDP的应用将在链路开启后失效。对于内网穿透或IP白名单验证等刚性需求场景，保持“通过代理”常开；对于三层或以上的多跳需求，果断转向Clash Meta或Surge等专业工具；无特殊需求时务必关闭该功能，维持常规单层代理的高效与稳定。
功能定位与典型适用场景
多层代理解决特定网络环境下的连接需求
Shadowrocket的“通过代理”功能构建的两层转发结构，本质上是为了应对单一代理节点无法独立完成连接的场景而设计的，例如企业内网要求所有出口流量先经过公司部署的SOCKS5认证网关，而用户又希望最终的访问IP落地在境外特定地区的节点上。在这种情况下，前置代理承担了认证和准入的职能，落地代理则负责提供目标地区的内容访问权限，两者分工协作完成完整的网络请求链路。与单层代理追求速度和低延迟不同，双层代理的核心价值在于打通被多层网络策略阻隔的通道，让原本无法直连的落地节点通过前置跳板获得可达性。
前置代理负责连接桥梁，落地代理决定最终出口
在双层代理结构中，落地代理是用户在Shadowrocket主界面选中的节点，它直接决定了目标服务器看到的最终访问IP地址和地理位置，所有向境外网站发起的请求都会以落地代理的IP作为源地址发出。前置代理则是用户在“通过代理”设置中指定的跳板服务器，它的作用是在本地设备和落地代理之间搭建一条可通行的中转通道，使得那些因网络策略限制而无法被本地直接访问的落地节点，能够通过前置代理的网络环境被连接。两者构成了“设备连接跳板、跳板连接落地”的串联关系，缺一不可。
该配置不适用于追求极致速度的日常浏览场景
由于数据包在传输过程中需要经历两次完整的代理协议封装和加密处理，每次转发都会引入额外的路由跳转和处理延迟，双层代理的总耗时通常比单层代理高出百分之五十以上。对于普通的网页浏览和视频观看场景，这种速度损耗带来的体验下降远大于任何隐私或伪装收益，因此除非用户确实面临前置认证或落地节点被本地网络屏蔽的刚性需求，否则不应为了“更安全”的主观感受而开启双层转发。
前置代理与落地代理的角色分工
落地代理负责与目标服务器完成最终通信
落地代理的配置方式与常规节点完全一致，用户可以在Shadowrocket主界面的节点列表中选择任意协议类型（Shadowsocks、VMess、Trojan等）的节点作为落地出口，该节点的性能和稳定性直接决定了用户最终访问境外网站的速度体验。落地代理的IP地址是目标网站直接看到的地址，因此在涉及账号地域锁定和内容区域限制的场景下，落地代理的地理位置必须与目标服务的要求相匹配。落地代理在双层结构中充当数据出口的角色，其配置参数与单层使用时完全一致，用户无需为双层结构对落地节点做任何特殊修改。
前置代理作为连接桥梁仅负责数据中转
前置代理在双层结构中扮演的是中转网关的角色，它接收来自本地设备的加密数据包，并将其完整转发至落地代理，再从落地代理接收返回数据并传回本地设备。前置代理本身不参与对目标网站的直接访问，也不决定最终出口IP，它的全部价值在于提供一个能够被本地设备连接且同时能够连接落地代理的网络中转点。由于前置代理只需完成简单的数据转发而不处理目标服务器的应答内容，其对带宽和处理能力的要求低于落地代理，但必须具备稳定的在线率和与落地代理之间低延迟的网络连接。
前置代理的出口网络必须能够访问落地代理的服务端口
在配置双层代理时最容易被忽略但最关键的技术前提是，前置代理所在网络环境必须能够与落地代理的服务器地址和监听端口建立网络连接。如果前置代理的出口IP与落地代理位于两个互相阻断的网络域中，或前置代理本身无法访问落地代理所使用的代理协议端口，那么数据包在前置代理处就会被丢弃而无法到达落地代理，整条链路完全瘫痪。用户在配置前应先在前置代理服务器上测试对落地代理地址的连通性，确认可达后再进行Shadowrocket的链式配置。
在设置界面完成双层链的具体操作步骤
主界面选定落地代理作为最终出口节点
用户首先在Shadowrocket主界面的节点列表中，选定一个延迟较低且与目标服务区域匹配的节点作为落地代理，该节点应当已经通过单层使用验证确认可以正常访问目标网站。选定的节点会在主界面顶部以高亮状态显示，后续所有经过代理的流量都将以此节点作为最终出口，该节点的协议类型和加密参数不受后续前置代理配置的影响。在进入前置代理配置前，建议先以单层模式测试该节点的连通性和访问速度，确认落地代理本身工作正常后再进行后续的链路叠加操作。
进入设置页面的“通过代理”选项填入前置跳板参数
完成落地代理选择后，用户点击底部导航栏的“设置”进入应用设置页面，向下滚动找到“代理”设置区域中的“通过代理”选项，点击进入配置界面。在该界面中，用户需要将前置跳板的服务器地址填入“主机”或“地址”字段，将监听端口填入“端口”字段，在“类型”下拉菜单中选择与前置跳板实际协议一致的SOCKS5或HTTP选项，如果前置代理启用了用户认证，还需在对应的用户名和密码输入框中填写认证凭据。所有参数填写完毕后，将页面顶部的“通过代理”总开关切换至开启状态，Shadowrocket会立即激活双层转发通道。
保存配置后验证出口IP是否切换为落地代理地址
完成配置并开启开关后，用户应立即在Safari浏览器中访问IP检测网站，观察当前显示的出口IP地址是否为落地代理的地址而非本地运营商分配的地址，同时确认该IP的地理位置与落地代理节点声明的区域一致。如果出口IP与落地代理地址吻合，则说明双层链路已成功建立；如果出口IP显示为前置代理的地址或本地IP，则表明配置存在错误或链路中断，需要返回配置界面检查前置代理的地址、端口和协议类型是否填写正确。验证通过后，用户即可正常使用双层代理访问所有需要代理的网站和服务。
前置代理的类型限制与填写注意事项
仅支持标准SOCKS5与HTTP协议作为前置跳板
Shadowrocket的前置代理功能在协议支持上有明确的限制，用户只能将SOCKS5或HTTP协议的代理地址填入“通过代理”配置中，无法直接填入另一个Shadowsocks、VMess或Trojan节点的连接参数。这意味着用户想要以某个加密协议节点作为前置跳板时，必须在该节点所在的服务器上额外部署一个SOCKS5协议转换服务，将该节点的加密流量转换为标准的SOCKS5接口供Shadowrocket调用。这一限制增加了配置的复杂性，大多数普通用户难以自行完成服务端的协议转换部署。
HTTP前置代理无法转发UDP和部分非网页流量
HTTP代理协议在设计中仅针对HTTP和HTTPS请求进行了优化，对于游戏UDP包、邮件IMAP协议以及自定义端口的TCP连接，HTTP代理无法提供可靠的转发通道。当用户选择HTTP代理作为前置跳板时，Shadowrocket会尝试通过HTTP CONNECT隧道来封装非网页流量，但这种隧道机制在遇到UDP数据包时往往会失败或降级为TCP传输，导致游戏和语音通话功能完全不可用。对于需要代理多种协议类型的用户，强烈建议选择SOCKS5而非HTTP作为前置代理，以获得更好的协议通用性。
前置代理的域名解析策略应设置为远程解析
当用户在前置代理配置中使用域名而非IP地址填写服务器地址时，Shadowrocket会首先通过本地网络解析该域名，再以前置代理为跳板进行后续连接。这种本地解析方式可能因本地DNS污染而获取到错误的服务器IP，导致前置代理连接失败。用户应确保前置代理所在服务器支持远程DNS解析功能，并在Shadowrocket的DNS设置中为前置代理域名配置独立的解析策略，尽可能直接使用IP地址填写以避免DNS层面的干扰。
链式代理开启后的性能损耗与潜在风险
双重加密与双重路由导致延迟显著增加
数据包在双层代理路径中需要经历完整的加密和解密流程两次，首先由本地设备对原始数据进行加密后发送至前置代理，前置代理解密后再次按照落地代理的协议要求重新加密并转发，整个过程重复了加密握手和加解密计算。叠加两次路由的物理距离，用户感知到的网络延迟通常是单层代理的一点五倍至两倍，在网页首屏加载和视频初始缓冲时会有明显的等待感。这种性能损耗是双层转发结构固有的特性，无法通过优化配置消除，用户必须在功能需求和速度体验之间做出取舍。
UDP流量在链式转发中几乎完全不可用
Shadowrocket对UDP数据包的处理机制在前置代理功能开启时会变得极为脆弱，即使是支持UDP转发的SOCKS5前置代理，在面对两次串联的UDP关联请求时也可能因状态同步问题而直接丢弃数据包。用户在开启双层代理后尝试进行外服游戏或VoIP通话，往往会发现游戏匹配完成后无法进入对局，或语音通话在接通瞬间即断开，这是UDP数据包无法在双层链路中维持稳定关联的典型表现。对于依赖UDP通信的应用，开启代理链之前必须充分考虑这一兼容性损失。
任意一跳失效即导致整条通道完全中断
双层链路的可靠性完全等同于两条单链可靠性的乘积，当前置代理或落地代理中的任意一个节点出现临时故障、网络波动或服务重启时，整个转发通道会在检测到断连后直接终止，用户会立即失去所有代理访问能力。Shadowrocket不会在当前节点失效后自动跳过前置代理回退至单层模式，也不会尝试切换至链路上的其他替代节点，恢复访问的唯一方式是用户手动关闭“通过代理”开关或切换至其他可用的节点组合。这种单点故障的放大效应使得双层代理的总体稳定性显著低于单层代理。
复杂多级需求下的替代工具建议
三层或以上转发需求超出Shadowrocket能力边界
Shadowrocket的双层结构已经是其代理链功能的上限，应用内部不存在任何配置路径能够将链路长度扩展至三层或以上。当用户面临需要经过香港、美国和欧洲三个节点依次跳转才能到达目标服务器的复杂路由场景时，继续在Shadowrocket中寻找解决方案只会徒劳无功。此时用户应当认清应用的功能边界，停止在现有工具上投入排障时间，转而评估能够满足多层转发需求的专业工具。
Clash Meta与Surge原生支持灵活的链式策略组
Clash Meta（及其移动端分支Stash、Chisel）和Surge在配置文件中提供了type为chain的策略组定义，用户可以自由组合任意数量的节点构建指定顺序的转发链路，并能够为不同的目标域名配置不同的链式策略组，实现精细化的多跳路由管理。这些工具在链式代理的协议支持、层级深度和与规则引擎的集成度上远超Shadowrocket，能够满足从两层到多层、从固定链路到动态选择的各种复杂需求。对于需要长期维护多级代理架构的用户，迁移至这些专业工具是更为经济和可持续的选择。
日常使用中无特殊需求应保持前置代理开关关闭
代理链功能在开启后会对全部流量施加额外的处理和转发开销，同时引入双重故障点和UDP兼容性风险，对于没有内网认证、IP白名单或特殊地域伪装等刚性需求的普通浏览场景，开启该功能并不会带来任何速度提升或稳定性增益。用户应将“通过代理”开关视为解决特定网络阻断问题的专项工具，仅在明确需要绕过本地网络对特定落地节点的访问限制时才临时开启，使用完毕后立即关闭，恢复至高效的常规单层代理模式。
常见问题FAQ
前置代理和落地代理的协议不同能正常工作吗？
可以正常工作。前置代理仅负责数据传输的中转，其协议类型只影响本地设备到前置代理之间的通信方式，与落地代理的加密协议完全独立。数据包到达前置代理后会以原始形式被转发至落地代理，再由落地代理按照自身协议完成与目标服务器的通信，两者互不干扰。
配置后连不上，怎么排查是前置还是落地的问题？
先在设置中临时关闭“通过代理”开关，直接测试落地代理在单层模式下能否正常连接和访问网页，如果单层模式失败则问题在落地代理。如果单层模式正常，再开启“通过代理”并在前置代理服务器上使用curl命令手动测试对落地代理地址和端口的连通性，确认前置代理的网络环境能否访问落地代理，以此来区分是前置代理的参数填写错误还是两者之间的网络链路不通。
开启代理链后订阅更新能正常进行吗？
订阅更新的拉取请求默认通过设备直连网络发出，不受前置代理和落地代理的链式转发影响。但如果用户在订阅设置中开启了“通过代理更新订阅”选项，订阅拉取请求也会经过完整的双层链路，此时前置代理必须能够访问订阅服务器地址，否则订阅更新会因链路中断而失败。
前置代理挂了，主节点会自动直连吗？
不会自动直连。在“通过代理”开关开启的状态下，落地代理必须经由前置代理完成连接，当前置代理不可用时整条链路会完全中断，Shadowrocket不会自动跳过前置代理回退至单层直连模式。用户必须手动进入设置页面将“通过代理”开关关闭，恢复单层代理模式后才能重新获得网络访问能力。