很多人第一次接触 sing-box 时，会把它和 Shadowsocks、VMess、Trojan 或 Hysteria2 放在同一层级比较，进而误以为 sing-box 也是一种代理协议。更准确地说，sing-box 是一个支持多种入站、出站、传输与分流能力的代理核心，同时也有可供不同平台调用的客户端形态；Shadowsocks、VMess、Trojan、Hysteria2、TUIC 和 WireGuard 则属于不同的通信协议或网络实现。两者的关系，类似于“播放器”和“音视频格式”：前者负责读取、组织和运行配置，后者决定具体如何建立连接。
选型时不能只看协议名称。实际体验还会受到线路结构、服务器负载、本地网络、DNS 处理方式、分流规则、客户端平台和应用兼容性的共同影响。本文从 sing-box 的工作方式出发，说明配置中各个模块如何协作，再对比常见协议在速度、延迟、功耗、兼容性与弱网环境下的特点，最后按照手机、游戏和日常使用场景给出可执行的选择方法。
sing-box 到底负责什么
sing-box 的核心任务，是接收应用产生的网络请求，根据配置决定如何处理，再通过指定的出站协议连接远端服务。它可以作为本地代理核心运行，也可以在部分平台上接管系统流量。配置中通常会出现入站、出站、路由、DNS 和实验性功能等部分，它们分别处理不同阶段的问题。
应用请求
→ 系统代理或 TUN 入站
→ 路由规则匹配
→ 直连、拦截或选择代理出站
→ 协议与传输建立连接
→ 远端服务器访问目标地址
→ 响应返回本地应用“入站”可以理解为 sing-box 接收流量的入口。常见形式包括本地 HTTP 代理、SOCKS 代理和 TUN。HTTP 与 SOCKS 通常只接管明确使用代理的应用，配置简单、排查直观；TUN 则通过虚拟网络接口接收更广泛的系统流量，适合那些不读取系统代理的程序，但对权限、DNS 和路由设置要求更高。
“出站”描述流量离开本机的方式。direct 表示直接连接目标，block 用于拒绝请求，代理出站则包含服务器地址、端口、认证、TLS、传输层和协议参数。sing-box 可以配置多个出站，再通过路由规则把不同域名、IP、端口或应用请求分配给不同出口。
因此，sing-box 并不会自动让某个协议变快。它提供的是统一的配置和调度框架，最终速度仍取决于协议实现、线路路径、出口服务器和目标服务。即使两条节点都使用同一种协议，如果一条经过公网直连、另一条经过中转或 IEPL 专线，实际表现也可能明显不同。
配置中的关键模块与连接逻辑
入站和出站
入站决定“哪些流量进入 sing-box”，出站决定“进入后从哪里出去”。只在客户端里导入节点，并不代表所有应用都会自动使用它。桌面应用通常可以读取系统代理，但部分终端工具、游戏启动器、浏览器扩展和独立客户端可能拥有自己的网络设置。若某个程序没有使用系统代理，可以考虑为它单独设置 SOCKS 或 HTTP 代理；需要接管更多系统流量时，再评估 TUN。
出站还可以承担选择和回退功能。例如日常网页请求走默认节点，国内服务使用 direct，广告或不需要访问的域名交给 block，特定工作应用则走固定地区节点。规则越多并不一定越好，复杂规则可能带来域名解析不一致、应用无法访问或更新后匹配失效等问题。配置应从少量明确规则开始，再根据实际需求增加。
路由与 DNS
路由规则负责回答“这个请求应该走哪条路径”。常见判断条件包括域名、域名后缀、IP 地址、端口以及网络接口。域名规则适合处理网站和服务分类，IP 规则适合处理已经解析出的地址，但两者的执行顺序要根据配置结构确认。部分应用使用硬编码 IP、QUIC 或自有解析机制，单纯添加域名规则未必能够覆盖。
DNS 则负责把域名转换为 IP。若请求通过代理发送，但 DNS 仍由本地网络直接解析，可能出现解析结果与出口地区不一致，或者得到不适合当前网络的地址。sing-box 可以为不同 DNS 请求指定服务器，并通过路由决定解析流量的处理方式。不过，DNS 设置不能脱离客户端平台单独理解：系统缓存、浏览器缓存、应用自带 DNS 和 IPv6 都可能影响最终结果。
如果使用 TUN，通常要一起检查虚拟接口、自动路由、DNS 劫持或接管、IPv4 与 IPv6 策略。没有必要一开始就打开所有高级选项。更稳妥的顺序是先用明确的系统代理验证节点，再逐步启用 TUN；每次只改变一项设置，便于知道问题来自代理、DNS 还是路由。
5
常见配置层次
90+
可选国家覆盖
200+
可选线路
不限
同时在线设备
这里的“5 个配置层次”是为了帮助理解：应用流量、入站、路由、DNS 和出站并不是 sing-box 的唯一字段分类，而是排查时最有用的观察顺序。实际配置还可能包括日志、缓存、实验功能和平台专属参数。阅读订阅时，不必逐行背诵 JSON；先定位流量从哪里进来、由哪条规则匹配、通过哪个出站离开。
常见协议怎么比较
协议比较应分成几个维度。吞吐量受加密开销和传输方式影响，延迟受握手过程与线路距离影响，功耗与重连频率、后台保活和移动网络切换有关，兼容性则取决于客户端是否支持对应协议及其参数。以下结论是选择方向，不是对所有服务器和网络环境的绝对排名。
| 协议或实现 | 主要特点 | 优势倾向 | 需要注意 |
|---|---|---|---|
| Shadowsocks | 结构相对简洁，生态成熟 | 客户端覆盖广，日常配置容易理解 | 不同插件、加密方式和传输设置会影响兼容性 |
| VMess | 常与特定传输层和 TLS 组合使用 | 历史客户端支持较多，迁移资料丰富 | 参数组合较多，旧配置可能与新客户端表现不同 |
| Trojan | 通常依赖 TLS 建立加密连接 | 配置结构清晰，适合常规 TCP 场景 | 证书、服务器名称和传输参数必须一致 |
| Hysteria2 | 基于 QUIC，面向 UDP 传输 | 在部分丢包或带宽变化环境中有较强适应性 | 网络对 UDP 的限制、客户端版本和服务器参数都很关键 |
| WireGuard | 轻量级 VPN 协议，工作在网络层 | 移动设备与全局流量场景中性能和配置较直观 | 分流、DNS 和应用级代理能力要看客户端实现 |
Shadowsocks 往往适合作为入门和日常备用选项，因为支持它的客户端较多，出现问题时比较容易找到对应设置。Trojan 常见于基于 TLS 的连接，重点不是名称本身，而是证书、服务器名称、端口和传输方式是否匹配。VMess 的历史兼容范围较广，但配置字段和组合较多，导入后最好不要随意改动传输参数。
Hysteria2 使用 QUIC 思路，底层依赖 UDP。它不等于在任何网络下都更快：如果当前网络限制或丢弃 UDP，连接可能无法建立，或者表现不如 TCP 方案。WireGuard 则更接近完整的网络层 VPN，适合需要较大范围接管流量的场景，但在复杂的按应用、按域名分流需求下，最终体验取决于客户端提供的路由能力。
动手导入配置并逐项验证
如果服务商提供订阅链接，通常可以在支持 sing-box 的客户端中直接添加订阅，也可以使用 Windows、macOS、Android、iOS 或 Linux 官方客户端。不同客户端的菜单名称会有差异，但操作逻辑基本一致：添加订阅、更新配置、选择节点、启动连接，再确认应用是否实际使用了代理。需要导入订阅时，可先参考站内的使用教程。
- 确认来源与客户端：安装与系统匹配的客户端，确认它支持订阅中实际出现的协议、TLS 和传输字段。不要把 sing-box 配置文件直接当成所有客户端都能识别的通用格式。
- 添加订阅：复制订阅链接后粘贴到客户端的订阅管理区域。订阅链接包含访问凭据，应避免放入公开文档或发送到不必要的群组。
- 更新并查看节点：执行更新操作，确认节点名称、地区和协议字段能够正常显示。如果列表为空，先检查链接是否完整、网络是否可访问，以及客户端是否支持该格式。
- 先测试系统代理：暂时使用规则较少的配置，选择一个节点启动连接。打开浏览器访问 IP 检测页面，核对公网出口和 DNS 结果，不要只看客户端显示的连接成功提示。
- 再测试目标应用：在实际需要使用的浏览器、工具或应用内测试。若浏览器正常而独立应用失败，优先检查该应用是否读取系统代理，而不是立即更换协议。
- 最后启用 TUN 或复杂分流：只有在系统代理无法覆盖需求时再启用 TUN。启用后重新检查本地服务、局域网设备、IPv6 和 DNS，必要时为内网地址设置直连规则。
测试时最好一次只改变一个变量。例如先固定节点和分流模式，再更换协议；先验证 TCP 方案，再验证 UDP 方案；先观察网页访问，再观察文件传输或长时间连接。若同时更换地区、协议、DNS 和 TUN，就算问题消失，也很难知道真正起作用的是哪一项。
- ✅ 订阅能够更新，且客户端识别出实际协议字段
- ✅ 连接后在同一设备、同一应用内核对出口地址
- ✅ 需要 TUN 时检查系统权限、DNS 与局域网访问
- ❌ 不要同时运行两个会接管系统流量的代理核心
- ❌ 不要把一次连接成功当成长期稳定的证明
按手机、游戏和日常使用场景选择
手机：优先考虑功耗与网络切换
手机经常在 Wi-Fi、移动数据和不同信号覆盖之间切换，因此协议能否快速恢复连接、客户端是否支持后台运行，以及 TUN 或 VPN 权限是否稳定，比理论峰值速度更重要。需要覆盖多个应用时，WireGuard 或客户端提供的 TUN 方案比较直观；只想让浏览器或单个应用使用代理，则可以优先采用系统代理或应用内代理，减少后台接管范围。
移动网络下，Hysteria2 的 UDP 特性可能在部分弱网环境中有帮助，但也必须确认当前运营商或网络环境没有明显限制 UDP。若连接经常消失，应先观察网络切换、系统省电策略和后台权限，再考虑协议本身。Android 与 iOS 对后台 VPN 的限制不同，不能把一个平台上的稳定性直接推断到另一个平台。
游戏：先看延迟稳定和 UDP 支持
游戏通常对延迟波动、丢包和连接方向更敏感，单纯追求下载速度没有意义。很多实时游戏依赖 UDP，若使用的代理模式只稳定处理 TCP，可能出现登录正常但匹配、语音或对战异常的情况。选择前应确认客户端是否能够接管游戏所需的流量，以及服务商是否明确说明游戏线路和对应地区。
Hysteria2 和 WireGuard 都可能适合需要 UDP 的环境，但这不是无条件推荐。游戏服务器距离、入口到出口的路径、NAT 类型和本地 Wi-Fi 质量，都会影响最终结果。建议先使用规则模式，仅让目标游戏及其必要服务经过指定节点，把更新、直播和其他本地服务留在直连，避免不必要的流量占用。
日常使用：规则模式通常更容易维护
日常使用往往同时包含本地网站、海外网站、视频、办公软件和系统更新。全局模式虽然简单，但会让所有流量经过同一出口，可能增加不必要的带宽消耗，也可能影响本地服务。规则模式可以把常用本地域名、局域网地址和办公系统设为直连，把需要远端访问的服务交给代理出站。
协议方面，Shadowsocks 和 Trojan 通常比较适合先建立稳定的基础配置；如果当前网络对 UDP 友好、客户端支持完善，再尝试 Hysteria2；如果更看重网络层覆盖和配置简洁，可以评估 WireGuard。VMess 则应根据订阅现有配置使用，不要仅因为名称熟悉就认为它一定优于其他选项。
| 使用场景 | 优先观察 | 可先尝试 | 常见误区 |
|---|---|---|---|
| 手机多应用 | 后台权限、功耗、切网恢复 | WireGuard 或支持 TUN 的方案 | 只看测速，不检查省电策略 |
| 游戏 | UDP、丢包、延迟波动 | WireGuard 或 Hysteria2 | 把网页能打开当成游戏可用 |
| 日常网页 | 兼容性、DNS、规则维护 | Shadowsocks 或 Trojan | 所有请求长期使用全局模式 |
| 多设备切换 | 客户端覆盖与订阅管理 | 统一订阅，按平台选择客户端 | 认为一个配置文件适合所有平台 |
连接异常时的排查顺序
sing-box 配置出现问题时，建议按照“订阅—客户端—节点—协议—路由—DNS—应用”的顺序检查。订阅无法更新，先不要研究分流；节点可以连接但网页无法打开，检查出站参数与 DNS；网页正常而某个应用失败，查看该应用是否使用系统代理、是否启用了自己的 DNS 或是否依赖 UDP。若只有部分域名异常，再检查规则集和 IPv4、IPv6 的处理。
日志是定位问题的重要依据，但不应只看“启动成功”。需要关注的是请求是否命中了预期规则、实际使用了哪个出站、DNS 是否返回地址、连接是在握手阶段失败还是建立后中断。配置文件中包含认证信息时，分享日志前应删除服务器地址、用户名、密码、密钥、订阅链接和其他凭据。
当多个客户端同时运行时，系统代理端口、TUN 路由和 DNS 接管可能互相覆盖。停止其他代理程序，重启当前客户端，再用最简单的节点和规则测试，通常比继续叠加参数更有效。更换网络环境后，也应重新验证；同一套配置在家庭宽带、办公网络和移动数据下可能需要不同的协议或路由策略。
- ✅ 先用单节点、少规则配置确认基础连接
- ✅ 记录每次修改的配置项，出现异常时能够回退
- ✅ 分别测试网页、长连接和实际目标应用
- ❌ 不要把 DNS 异常、线路拥塞和客户端不兼容混为一谈
- ❌ 不要公开包含订阅凭据的配置文件或完整日志
总体而言，sing-box 的价值在于把不同协议、线路和分流逻辑放进同一个可管理框架，而不是替用户自动决定“最好”的协议。对大多数人来说，稳定的订阅、兼容当前平台的客户端、清晰的规则和可替换的备用节点，比复杂参数更重要。若需要多台设备使用，可根据 Windows、macOS、iOS、Android 和 Linux 的支持情况分别导入订阅；同时在线设备数不限，但每台设备仍需单独完成客户端配置与连接验证。