zfl9
ss-tproxy 可以针对“本机”和“局域网内的其他主机”进行透明代理。 - “本机”是指当前 network namespace - “局域网内其他主机”，这个很好理解
> 好的，感谢，还想请教一个问题，clash就算开启了tproxy端口之后，如果没有按ss-tproxy中的内容配置相关内容的话，直接将流量转发至clash的端口的话，是不是代理也不会生效呀，必须开启tproxy端口 + ss-tproxy配置才是可以的呢 如果你说的“端口”是tproxy端口，那么流量必须经过 ss-tproxy 所在 network namespace 的 iptables(netfilter) 规则处理，通过 REDIRECT/TPROXY 的方式送往 clash 进程。你直接使用其他方法将流量导入 tproxy 端口是行不通的。 如果是 socks5 端口，那么导入此端口的流量也必须是 socks5 协议。 总之核心就是，必须与“端口”的传入协议相匹配（tproxy你也可以理解成一种协议）。
> 跨容器（network namespace）的透明代理，我没有测试过，最好不要这么做，除非你深刻理解透明代理和docker容器之间的网络模型。 > > 我建议你把 ss-tproxy 和 相关的代理进程（clash）运行在宿主机而不是容器内，或者，如果要使用容器，那么 ss-tproxy 所在容器的网络要使用 host（即，宿主机的 network namespace），而不是默认的 bridge（会创建单独的 network namespace）。 > > ss-tproxy 的“本机”代理，仅限当前 network namespace。如果要跨 network namespace，必须抽象出一个“局域网”，将其他主机(network namespace)的网关和dns指向 ss-tproxy 主机(network namespace)所在 IP。...
我没记错的话，tproxy 与 docker 的 bridge 有些冲突，具体请看 wiki/常见问题
是的，必须经过内核redirect/tproxy规则处理是为了给数据提供元信息(目标ip和目标端口)，没有这些元信息是没办法完成代理的，因为拿不到原始的目标地址。 socks等协议本质上也是传递这个元信息，只是方式不同罢了。
建议用 ss-tproxy 脚本，或者你可以说下你的需求：全局代理？还是gfwlist分流？还是chnroute分流
TCP好搞定，UDP的话，要设置TPROXY规则，想省事的话还是上 ss-tproxy 脚本，global模式，selfonly=true
你只需要将 “代理套件” 替换为 ipt2socks + 上游的socks代理，就能理解了。 另外，在 VPS 上运行并没有什么特别之处，无非就是只代理 VPS 本机罢了，也即 selfonly='true'
如果我没理解错的话，你是想代理 VPS 本机传出的流量，将其导入至指定的 socks5 服务器？ > 我想在VPS上实现全局的透明代理，将所有端口上的TCP以及UDP流量都转发到socks5 服务
那就没问题，ss-tproxy + mode=global + selfonly=true 代理相关的配置，可以参考【trojan(socks5)】，只不过把trojan去掉，配置ipt2socks就行