在Shadowrocket中启用代理链时，用户首先在主界面选择作为最终出口的主代理节点，然后进入“设置”页面找到“通过代理”或“Via Proxy”选项，在配置界面中填入前置跳板的服务器地址、端口、协议类型（仅限SOCKS5或HTTP）及认证信息，开启开关后应用会自动将主节点的流量通过前置跳板进行中转，形成“设备→前置代理→主代理→目标服务器”的两级转发链路。配置完成后通过访问IP检测网站并查看连接日志验证链式转发是否按预期工作，若出口IP为主节点地址则配置成功。需要注意该功能仅限于两层代理结构，无法扩展至三层或以上层级，且开启后UDP流量的兼容性会受到显著影响，外服游戏和VoIP通话可能因UDP数据包无法正确封装而完全失效。对于需要三层或以上跳转、精细化链式路由分配或配置文件语法定义链式策略组的场景，用户应当放弃Shadowrocket并转向Clash Meta或Surge等原生支持链式策略组的专业工具。日常使用中若没有内网穿透或IP白名单认证等特殊需求，建议保持该开关关闭以避免不必要的性能损耗和故障风险。
代理链功能的核心定义与支持范围
Shadowrocket支持两层代理链但限于特定协议类型
Shadowrocket确实提供了代理链功能，其在应用内被命名为“通过代理”或“Via Proxy”，该功能允许用户将当前选中的主代理节点通过另一个前置代理节点进行中转，形成“设备→前置代理→主代理→目标服务器”的两级转发链路。然而该功能的支持范围存在明确限制，作为跳板的前置代理仅接受HTTP代理和SOCKS5代理两种协议类型，用户无法直接将Shadowsocks、VMess或Trojan节点设置为上级跳板，这一约束源于协议栈的兼容性设计，因为SOCKS5和HTTP作为通用代理协议能够被绝大多数代理软件识别和转发，而加密代理协议则缺少标准化的链式转发接口。
代理链的层级数量被限制在两级以内
Shadowrocket的代理链实现仅允许构建两层转发结构，即设备发出的数据包先抵达第一个代理节点（前置跳板），再由该节点转发至第二个代理节点（主出口），最终到达目标服务器。应用内部不存在任何配置选项能够将链式长度扩展至三层或以上，这意味着用户无法实现类似“设备→香港节点→美国节点→欧洲节点”的多级跳转路径。对于需要三层或以上转发的复杂路由需求，Shadowrocket的功能边界已经达到上限，用户必须转向Clash Meta、Surge等支持原生链式策略组的专业代理工具。
配置界面位于设置路径而非配置文件中
与Clash或Surge在配置文件中通过proxy-groups定义链式策略组的方式完全不同，Shadowrocket的代理链功能通过图形界面进行配置，用户需要进入应用的“设置”页面，找到“代理”区域中的“通过代理”选项并手动填入前置代理的地址、端口、协议类型及认证信息。这一配置方式意味着用户无法在配置文件中以声明式语法定义链式逻辑，也无法将代理链与分流规则进行动态关联，所有的链式转发决策都是全局性的而非基于域名或策略组的精细化控制。
配置两层代理链的具体操作步骤
在主界面选定作为最终出口的主代理节点
用户首先在Shadowrocket主界面的节点列表中，选择希望作为最终出口节点的主代理，该节点负责将数据包最终发送至目标服务器，因此应选择延迟较低且带宽充足的节点。该主节点可以是Shadowsocks、VMess、Trojan等任意Shadowrocket支持的协议类型，因为代理链的层级关系是在应用内部通过本地转发实现的，上层协议类型不影响主节点的选择范围。选中主节点后保持其在列表中的激活状态，该节点将在后续的链式转发中担任第二跳的角色。
进入设置页面的“通过代理”区域填入前置跳板信息
完成主节点选择后，用户进入Shadowrocket的“设置”页面并滚动至“代理”相关区域，找到“通过代理”或“Via Proxy”选项并点击进入配置界面。在该界面中，用户需要填写前置代理跳板的完整连接参数，包括服务器地址（IP或域名）、端口号、代理类型（SOCKS5或HTTP）以及可选的用户名和密码认证信息。前置代理必须与主代理节点处于不同的物理位置，且具备与主代理之间稳定快速的网络连接，否则整个链路的延迟会被前置跳板的低质量链路拖累。
开启“通过代理”开关并验证链式转发路径
所有参数填写完毕后，用户将“通过代理”开关切换至开启状态，Shadowrocket会立即将所有经过主节点的流量重新路由至前置代理再发出，形成完整的链式转发路径。验证配置是否成功的最直接方式是开启连接日志并访问IP检测网站，观察日志中是否存在两条连续的代理连接记录，以及出口IP是否为最终主代理节点的地址而非前置代理的地址。如果出口IP与主节点不一致或连接超时，说明前置代理不可达或配置参数存在错误，需要返回配置界面重新核对地址和端口信息。
前置代理节点类型限制与格式要求
SOCKS5代理作为跳板时需确认支持远程DNS解析
当用户将SOCKS5代理配置为前置跳板时，需要确保该SOCKS5服务器支持远程DNS解析功能，即能够接受客户端发起的DNS查询请求并代为解析目标域名。如果前置SOCKS5代理不支持远程DNS，Shadowrocket会尝试在本地完成DNS解析后再将IP地址发送至前置代理，这可能导致目标域名的解析结果受本地网络环境干扰而不符合预期。用户在与服务商确认SOCKS5代理的配置细节时，应明确询问是否开放了远程DNS转发能力，若不支持则需要评估该跳板对整体分流精度的影响。
HTTP代理作为跳板无法转发HTTPS以外的流量类型
HTTP代理协议的设计初衷仅处理HTTP和HTTPS请求，对于非网页流量的UDP数据包、邮件协议或自定义端口的TCP连接，HTTP代理无法进行有效转发。当用户选择HTTP代理作为前置跳板时，Shadowrocket会尝试将非HTTP流量封装在CONNECT隧道中进行转发，但这一做法存在兼容性问题，部分应用可能因隧道建立失败而完全无法通信。对于需要代理多种协议类型的用户，强烈建议优先选用SOCKS5而非HTTP作为前置跳板，因为SOCKS5在协议层面的通用性远超HTTP代理。
前置代理不支持加密协议直连的约束解释
用户可能会疑惑为什么不能直接将另一个Shadowsocks节点填入“通过代理”地址，原因在于Shadowrocket在实现代理链功能时采用的是标准代理协议的连接接口，而Shadowsocks、VMess等加密协议需要完整的客户端握手和加密协商流程，无法通过简单的地址和端口参数进行连接。若用户希望以加密协议节点作为前置跳板，必须在该节点所在服务器上额外部署一个SOCKS5转换服务，将加密协议的流量转换为标准的SOCKS5接口供Shadowrocket调用，但这种方案需要用户自行维护服务端配置，不适用于普通节点使用场景。
与Clash配置文件中链式策略组的本质区别
Clash的chain类型策略组支持任意层级组合
在Clash格式配置文件中，用户可以创建一个type: chain的策略组，并在proxies列表中按照期望顺序排列多个节点名称，Clash会按照列表顺序将数据包逐级转发，支持从两层到多层任意长度的代理链。这一实现方式基于Clash核心的路由引擎，每个链式策略组在实际使用中表现为一个逻辑节点，可以被配置文件中的分流规则直接引用，与普通节点或策略组的使用方式完全一致。相比之下Shadowrocket的代理链功能仅存在于设置界面中的全局开关，无法与配置文件的分流规则产生任何联动，用户要么全局使用代理链，要么完全关闭。
链式策略组可与规则引擎联动而Shadowrocket的代理链是全局固定
Clash用户可以在规则列表中为不同的目标域名或IP段指定不同的链式策略组，例如将YouTube流量指向包含香港和美国的双节点链，将Netflix流量指向包含日本和新加坡的另一条链，每条链独立管理互不干扰。Shadowrocket的“通过代理”设置是全局唯一的，一旦开启，所有经过主节点的流量无论目标是什么都会被强制先经过前置跳板，用户无法针对特定网站或应用动态切换链式路由路径，这种粗粒度的控制方式在需要精细化分流的场景下显得力不从心。
配置文件语法层面完全不支持chain类型定义
用户如果在Shadowrocket的配置文件中尝试写入type: chain或类似Clash语法的策略组定义，应用在加载配置时会将整行忽略或直接报错，因为Shadowrocket的配置解析器不支持该类型的策略组声明。Shadowrocket的配置文件语法主要以分流规则、策略组（select/url-test/fallback）和节点定义为核心，缺少Clash和Surge中关于链式代理的任何实现。用户在查阅Shadowrocket官方文档或社区教程时，应明确认识到该应用的功能定位偏向轻量化的单层代理管理，而非复杂的链式路由编排。
代理链开启后的性能损耗与故障风险
两层加密和解密操作叠加导致CPU负载上升
代理链的每一跳都需要完成一次完整的加密和解密循环，数据包在发出前经过主节点的加密处理，到达前置代理后需要被解密再重新封装发送至主节点，最终到达目标服务器前再次经历解密过程。整个流程中的加解密操作次数是单层代理的两倍，对设备CPU的占用显著增加，在较旧的iPhone机型上可能表现为设备发热和电池续航明显缩短。同时每增加一跳加密解密环节，数据包在路径上停留的总时间也相应延长，网页加载的感知延迟会比单层代理高出数十至上百毫秒。
任意一跳失效即导致整个链式通道完全中断
代理链的可靠性遵循木桶效应，链路上的任何一个节点出现故障或网络波动，整个转发通道都会立即中断，且Shadowrocket在“通过代理”开启状态下不会自动跳过失效的跳板尝试直连或切换至其他备用节点。前置代理即便仅出现短暂丢包，主节点的稳定性能也无法发挥作用，用户的网络访问完全依赖于链路上最脆弱的一环。这一特性要求用户在选择前置跳板时必须对其运行时间和服务质量有充分的信心，任何临时性的节点维护都可能使整个代理方案陷入瘫痪。
链式转发中UDP流量的兼容性极差
Shadowrocket的代理链功能在TCP层面的表现尚可，但对于UDP流量的处理则存在严重的兼容性问题。即使主节点和前置代理都支持UDP转发，Shadowrocket在处理链式UDP请求时也可能因协议栈无法正确建立两层UDP关联而直接丢弃数据包，导致外服游戏和VoIP通话等功能完全无法使用。对于依赖UDP通信的应用场景，开启代理链几乎等同于主动放弃这些服务的可用性，用户应谨慎评估是否值得为了IP隐藏而牺牲游戏和语音的使用体验。
替代方案与适用场景的综合建议
前置代理仅用于内网穿透或特定认证场景
代理链功能在Shadowrocket中最有价值的应用场景是连接一个需要特定内网认证或IP白名单验证的前置网关，例如企业内网环境中的SOCKS5代理需要先通过认证才能访问外部网络，此时将企业代理设置为前置跳板，主节点选择常规境外节点，即可在满足内网合规要求的同时获得境外访问能力。这种组合利用了两层代理的不同职能分工，而非单纯为了构建多跳匿名路由，是代理链功能最合理的实际使用方式。
需要多层代理时应放弃Shadowrocket转向专业工具
如果用户的核心需求是实现三层或以上的跳转路径，或希望通过配置文件为不同流量指定差异化的链式路由，Shadowrocket的功能架构已经完全无法满足，此时继续在Shadowrocket生态内寻找解决方案只会浪费时间。用户应果断切换至Clash Meta（如Stash或Chisel客户端）或Surge等支持原生链式策略组的专业代理工具，这些工具在配置文件中通过proxy-groups的chain类型提供无限层级组合，并能够与规则引擎无缝集成，实现精细化的多跳路由管理。
日常使用中无特殊需求应保持代理链关闭
代理链功能在开启后会对所有流量施加额外的处理和转发开销，同时引入新的故障点和兼容性风险，对于日常网页浏览、视频观看和常规访问场景没有任何速度提升或稳定性增益。除非用户确实面临内网认证或严格的IP隐藏要求，否则在Shadowrocket设置中应始终保持“通过代理”开关处于关闭状态，仅依赖标准的分流规则和单层代理满足所有网络需求，这样既简化了排障路径也保持了最优的网络性能。
常见问题FAQ
Shadowrocket的代理链最多支持几层？
Shadowrocket的代理链功能仅支持两层转发，即“设备→前置代理→主代理→目标”，应用内部没有提供扩展到三层的配置选项。如果用户尝试在前置代理设置中再次套用一个代理，会发现“通过代理”字段本身只接受直接的服务器参数而不支持递归引用，因此任何三层以上的链式需求都无法在Shadowrocket中实现。
前置代理和主代理的协议类型必须相同吗？
不需要。前置代理仅接受SOCKS5或HTTP协议，而主代理可以是Shadowrocket支持的任何协议类型包括Shadowsocks、VMess、Trojan等，两者协议完全独立，数据包在前置代理完成SOCKS5转发后再由主节点按照自身协议进行加密传输，互不干扰。
开启代理链后节点测速功能还能正常使用吗？
可以正常使用，但测速结果反映的是经过两层代理完整转发后的综合延迟和带宽，而非主节点自身的性能数据。如果用户希望单独测试主节点而不受前置代理影响，需要在测试前临时关闭“通过代理”开关，测试完成后再重新开启。
代理链能配合规则模式的分流规则一起使用吗？
能，但有限制。“通过代理”功能作用于全局连接层面，开启后所有经过主节点的流量都会被前置转发，而规则模式的分流规则仅决定哪些流量走主节点、哪些走直连。两者结合的效果是所有被标记为代理的流量都会进入链式通道，而直连流量则完全不经过任何代理，两者在功能上互不干扰但无法实现不同域名走不同代理链的精细化控制。