TODO

[zfl9]

已完成：

• [x] 移除过时特性，如 proxy_svraddr4、proxy_svraddr6 放行机制
• [x] 尝试将 dns 组件设计为可选，方便高级用户自定义 dns 方案
• [x] 跟进 chinadns-ng 近期更新的相关新特性
• [x] 优化易用性，调整默认设置，尽量开箱即用
• [x] 简化依赖安装，chinadns-ng、ipt2socks、dns2tcp 已提供预编译二进制
• [x] gfwlist.txt 更新不再依赖 perl 转换，直接用别人转好的域名列表，增强移植性
• [x] 尝试给 chnroute 加个黑名单，强制某些特殊域名走代理（白名单扩展已有）
• [x] 使用 chinadns-ng 2.0 替代 dnsmasq/dns2tcp
• [x] dns_direct*、dns_remote* 允许配置多个 DNS #262
• [x] 处理 TCP/53 上的 DNS 流量（iptables 规则）
• [x] 支持 DNS over TLS 上游 (见 chinadns-ng 2.0）

---

TODO：

• [x] 提供 docker 镜像，简化使用步骤（有了安装脚本就不考虑这个了）
• [ ] 提供一个脚本，用于 安装和交互式配置（附带常见配置的example）
• [ ] 提供 nftables 版本，暂时没时间弄，请使用 iptables-nft 切换至 nf_tables 后端

[fengqi]

期待dns自定义和gfwlist，我是在openwrt网关上使用，为了配合已有的dnsmasq不得不魔改，因为涉及到dhcp、mac绑定、host等很多内置功能。

[zfl9]

除了nft，其他基本上完成，大概明两天发布4.7版本

新版本对iptables规则做了不少优化，以尽量减少规则数，提升性能(代理性能，直连性能)。。

[zfl9]

见 v4.7 版本。

[bluehj777]

非常喜欢作者的这个项目，很适合部署在单独的网关上使用，还可以方便接入自己的脚本实现更丰富功能。多年来一直稳定运行，感谢作者的工作。这次看来是夸版本升级，改动比较大，准备跟进体验。btw:nft版本是什么意思？

[zfl9]

nft 就是指 nftables。

[bluehj777]

nft 就是指 nftables。

啊！😁我还特意去google了下，结果都是元宇宙，加密货币相关，给整蒙了。

[bluehj777]

是否考虑引入pf的构建，这样就有bsd系统的原生支持了，nftables对比iptables除了更灵活，易用，就目前ss-tproxy要处理的规则量估计有不会有太多优势展现吧

[cattyhouse]

现在有代理程序支持 pf 嘛? 没有吧.

[bluehj777]

我理解的ss-tproxy就是操作iptable的规则来处理流量，把它按希望的方式交给代理程序客户端出站吧。所以它不关心客户端运行的是ss 还是xray v2ray 或者什么其他的吧。比如v2ray就支持freebsd平台，客户端可以在上面运行，而bsd系统上原生用的是pf，我想它应该是和iptables类似的东西吧。只不过规则语法不同。BSD我也是接触的很肤浅，也许我的理解不对。(freebsd也是可以安装iptables和nftables，不过不是原生的防火墙)

[zfl9]

支持 pf 的客户端很少，目前不考虑。

[xtccc]

nftables 的好处之一是 可读性比iptables好点

[sunlewuyou]

[zfl9]

因为本人时间精力有限（至少这段时间是这样，过段时间应该会抽点空干点 TODO 事项）

如有遇到实在是搞不定的 ss-tproxy 问题，可以看下其他同类项目，比如基于 Web GUI 的 v2rayA

当然，我更希望有更多小伙伴能参与 ss-tproxy 的开发，帮忙清扫 TODO 清单，增强易用性~

最后，感谢大家对 ss-tproxy 的支持。

[bluehj777]

因为本人时间精力有限（至少这段时间是这样，过段时间应该会抽点空干点 TODO 事项）

如有遇到实在是搞不定的 ss-tproxy 问题，可以看下其他同类项目，比如基于 Web GUI 的 v2rayA

v2rayA不支持xray。 还是ss-tproxy脚本方式的方便灵活嵌入自己的应用场景

[zfl9]

因为本人时间精力有限（至少这段时间是这样，过段时间应该会抽点空干点 TODO 事项） 如有遇到实在是搞不定的 ss-tproxy 问题，可以看下其他同类项目，比如基于 Web GUI 的 v2rayA

v2rayA不支持xray。 还是ss-tproxy脚本方式的方便灵活嵌入自己的应用场景

对于有一定基础的用户，相比于 v2rayA，ss-tproxy 应该会是一个更好的选择。

但如果使用者没有一些基本的调试问题的能力（比如最基础的看日志这种），那使用 ss-tproxy，除非一次性成功，不然一旦出问题，调起来对双方都很累 :joy:。只能说，希望大家都互相理解下。

当然，很大部分原因是 readme/wiki 等文档说明不够清楚。有一些细节我以为大家懂，不必啰嗦的写，但事实证明我错了。

[wnpllrzodiac]

因为本人时间精力有限（至少这段时间是这样，过段时间应该会抽点空干点 TODO 事项） 如有遇到实在是搞不定的 ss-tproxy 问题，可以看下其他同类项目，比如基于 Web GUI 的 v2rayA

v2rayA不支持xray。 还是ss-tproxy脚本方式的方便灵活嵌入自己的应用场景

对于有一定基础的用户，相比于 v2rayA，ss-tproxy 应该会是一个更好的选择。

但如果使用者没有一些基本的调试问题的能力（比如最基础的看日志这种），那使用 ss-tproxy，除非一次性成功，不然一旦出问题，调起来对双方都很累 😂。只能说，希望大家都互相理解下。

当然，很大部分原因是 readme/wiki 等文档说明不够清楚。有一些细节我以为大家懂，不必啰嗦的写，但事实证明我错了。

如果有开箱即用的docker镜像，就容易使用多了。现在的配置项还是非常多的。链路中的节点环节也挺多的。不过自己熟悉一下，整个网络侧的知识能学到非常多东西。dns，dig，iptables，巴拉巴拉。

[zfl9]

主要还是 透明代理 本身涉及的组件比较多，还和内核层有牵扯。

另外就是，ss-tproxy 本身并不关心用的是什么代理客户端（ss、v2ray、xray、naive、clash等等），如果要提供 docker 镜像（或者一键脚本），那么该如何处理 不同客户端 的问题？

• 给每种 代理客户端 都单独编写逻辑，包括 安装/配置/启动 等等。工作量太大，维护成本高，仅靠我个人无法实现。
• 另一种思路就是，将此问题交给使用者，让用户负责 代理客户端 的 安装/配置/启动。那和现在的方式也没多大区别。

[zfl9]

所以，如果提供 一键脚本、docker镜像，那么也只是针对 ss-tproxy 脚本自身以及相关依赖（dnsmasq、chinadns-ng 等）进行一个简单的 打包/分发 处理。

但总的来说，这并没有完全解决问题，因为不同代理客户端的特性不一样，比如是否支持纯 tproxy（这个和内核是否支持还有关系），是否支持 udp，是否需要设置 snat 规则等等，任意一处配置不当，都可能出现代理跑不通的问题。

[xtccc]

所以，如果提供 一键脚本、docker镜像，那么也只是针对 ss-tproxy 脚本自身以及相关依赖（dnsmasq、chinadns-ng 等）进行一个简单的 打包/分发 处理。

但总的来说，这并没有完全解决问题，因为不同代理客户端的特性不一样，比如是否支持纯 tproxy（这个和内核是否支持还有关系），是否支持 udp，是否需要设置 snat 规则等等，任意一处配置不当，都可能出现代理跑不通的问题。

我的意见 如果是搞镜像 肯定是都让他们使用1080socks 出栈，通过ipt2socks转成ip包，别搞什么原生的透明代理

[zfl9]

所以，如果提供 一键脚本、docker镜像，那么也只是针对 ss-tproxy 脚本自身以及相关依赖（dnsmasq、chinadns-ng 等）进行一个简单的 打包/分发 处理。 但总的来说，这并没有完全解决问题，因为不同代理客户端的特性不一样，比如是否支持纯 tproxy（这个和内核是否支持还有关系），是否支持 udp，是否需要设置 snat 规则等等，任意一处配置不当，都可能出现代理跑不通的问题。

我的意见 如果是搞镜像 肯定是都让他们使用1080socks 出栈，通过ipt2socks转成ip包，别搞什么原生的透明代理

有道理，默认采用 ipt2socks + socks5 传入（具体配置由使用者负责，这个应该很简单了，代理进程可以跑在本机，也可以跑在其他内网机器），当然我也会尽可能提供另一种选择，那就是直接 tproxy/redirect 传入（对接本机代理进程的 60080 端口，设置上对于用户来说也不复杂，和 socks5 传入差不多）。