zfl9
按照clash的配置在docker上部署，似乎是没有生效，可以帮忙看下吗
端口错了，要么修改 clash.yaml 把 tproxy-port 改为 60080 (同readme的配置)，要么修改 ss-tproxy.conf，把 proxy_tcpport 和 proxy_udpport 改为 7893，总之必须保持一致。
端口错了，要么修改 clash.yaml 把 tproxy-port 改为 60080 (同readme的配置)，要么修改 ss-tproxy.conf，把 proxy_tcpport 和 proxy_udpport 改为 7893，总之必须保持一致。
好的，我修改了...但是....
这个情况你了解么？话说为什么百度也走了代理呀，不好意思，我是该领域的小白0.0
端口错了，要么修改 clash.yaml 把 tproxy-port 改为 60080 (同readme的配置)，要么修改 ss-tproxy.conf，把 proxy_tcpport 和 proxy_udpport 改为 7893，总之必须保持一致。
这是我的clash配置
这是我的ss-tproxy配置
端口已经改为和clash一致 其他选项均是默认配置
clash配置问题？先自己检查下吧。readme的clash配置是测试过的，另外你说在docker部署？ss-tproxy在docker容器内？curl/wget 在宿主机？
clash配置问题？先自己检查下吧。readme的clash配置是测试过的，另外你说在docker部署？ss-tproxy在docker容器内？curl/wget 在宿主机？
搞了半个月没搞出来，我是在k8s集群部署的，clash是一个容器，wget是在另一个容器里面（这个容器里面用envoy把80流量拦截转发到clash容器的7893端口了，在这个容器里面通过环境变量http_proxy是能生效的），不知道您是否了解这方面...只要能提供帮助的话0.0
还有为什么你的 start_clash 会漏出 clash 日志？readme 里面已经把 stdout stderr 重定向到日志文件了呀。
我改了一下这个，输出到控制台了.
跨容器（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。
跨容器的透明代理，我没有测试过，最好不要这么做，除非你深刻理解透明代理和docker容器之间的网络模型。
我建议你把 ss-tproxy 和 相关的代理进程（clash）运行在宿主机（或者 ss-tproxy 所在容器的网络使用 host），而不是容器内，否则你只能在 ss-tproxy 所在容器“实现”透明代理（理论上，未经测试）。
好的，感谢，还想请教一个问题，clash就算开启了tproxy端口之后，如果没有按ss-tproxy中的内容配置相关内容的话，直接将流量转发至clash的端口的话，是不是代理也不会生效呀，必须开启tproxy端口 + ss-tproxy配置才是可以的呢
ss-tproxy 可以针对“本机”和“局域网内的其他主机”进行透明代理。
- “本机”是指当前 network namespace
- “局域网内其他主机”，这个很好理解
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。
更新了一下。
好的，感谢，还想请教一个问题，clash就算开启了tproxy端口之后，如果没有按ss-tproxy中的内容配置相关内容的话，直接将流量转发至clash的端口的话，是不是代理也不会生效呀，必须开启tproxy端口 + ss-tproxy配置才是可以的呢
如果你说的“端口”是tproxy端口，那么流量必须经过 ss-tproxy 所在 network namespace 的 iptables(netfilter) 规则处理，通过 REDIRECT/TPROXY 的方式送往 clash 进程。你直接使用其他方法将流量导入 tproxy 端口是行不通的。
如果是 socks5 端口，那么导入此端口的流量也必须是 socks5 协议。
总之核心就是，必须与“端口”的传入协议相匹配（tproxy你也可以理解成一种协议）。
对对对我就是疑问这个，如果是这样的话，那我就一直理解错误了。我一直以为clash开启了tproxy端口7893之后，只要将其他TCP流量直接转发到这个端口，就能完成代理。比如我可以直接将访问google的tcp流量转发到这个端口就可以实现代理访问了。
是的，必须经过内核redirect/tproxy规则处理是为了给数据提供元信息(目标ip和目标端口)，没有这些元信息是没办法完成代理的，因为拿不到原始的目标地址。
socks等协议本质上也是传递这个元信息，只是方式不同罢了。
是的，必须经过内核redirect/tproxy规则处理是为了给数据提供元信息(目标ip和目标端口)，没有这些元信息是没办法完成代理的，因为拿不到原始的目标地址。
socks等协议本质上也是传递这个元信息，只是方式不同罢了。
非常感谢~~~