不少人以为拿到一组代理IP的地址和端口，就能像拨号一样直接填进软路由后台。实际动手才发现，这类系统原生并不认这种接入方式，填进去也没有入口。它的原生客户端面向的是隧道类协议，代理类要另装组件做转换。先弄清设备支持哪一类协议，再决定走哪条路，能省掉一半折腾。
- 确认原生支持 先查固件里内置的客户端面向哪一类协议。
- 确定走法 能直接用原生协议就直接用，不能用再考虑装转换组件。
- 装转换组件 容器或旁路网关都能做协议转换，二选一即可。
- 补参数 把代理IP的四项或三项信息按组件要求分别填好。
- 配分流规则 按设备或网段指定走哪条，再逐台核对地址。
两种走法各适合谁
原生协议这条路短，参数少，配置完直接在后台看连接状态，出问题也好定位。转换组件这条路长一些，要管环境、网络和规则，适合手上已经有一批代理类资源、又愿意花时间调试的人。两条路没有高下，区别在于你手上有什么资源、愿意投入多少时间。
转换那条路的坑在哪
转换组件的网络地址不能和局域网冲突，容器网段要和实际创建时一致，日志里看不到报错不代表接好了。装完先单独测一次转换服务能不能通，再去后台加连接，最后才配分流。三步分开验，比一口气配完再排错省时间。
分流规则为什么总漏
连接成功和流量走对是两件事。后台显示已连接，只说明这条代理IP拨上了，指定设备有没有走它，还得看规则写没写、写对没写对。漏写一条，对应那台设备就还在走默认通道。
先定协议，再选走法，最后才动手配，顺序反了容易白装一遍组件。
同一台设备上，两类协议的线路建议分开管理，混在一起容易认错。
设备支持什么，比你想用什么更重要。
归纳三点：一是先查设备原生支持哪类协议；二是能用原生协议就别急着装组件；三是无论走哪条路，最后都要逐台核对实际地址。三点都做到，配置过程就不会来回返工。