zfl9 / ss-tproxy Goto Github PK

搭建 SS/SSR/V2Ray/Trojan/Socks5 透明代理的 Shell 脚本

License: GNU Affero General Public License v3.0

Shell 100.00%

chnroute clash gfwlist hysteria iptables naive nftables proxy shadowsocks socks5 ss ss-tproxy ssr tproxy transparent-proxy trojan v2ray xray

ss-tproxy's Issues

求助，使用shadowsocks-libev，但无法解析域名

尝试用一台CentOS 7.5云服务器搭建ss-tproxy，但是无法解析域名
访问Google的IP地址http://172.217.161.36，可以成功返回，但是方位http://www.google.com则提示无法解析域名。
服务端是自建的，支持udp，如下是配置文件：

## mode
mode='global'
#mode='gfwlist'
#mode='chnroute'

## proxy
proxy_tproxy='false'   # 纯TPROXY方式
proxy_server=(47.*.*.*)   # 服务器的地址
proxy_dports='443'        # 服务器的端口
proxy_tcport='60080'   # TCP 监听端口
proxy_udport='60080'   # UDP 监听端口
proxy_runcmd='(ss-redir -s 47.*.*.* -p 443 -m aes-256-cfb -k ******** -b 0.0.0.0 -l 60080 -u -v >>/var/log/ss-redir.log 2>&1 &)'  # 启动的命令行
proxy_kilcmd='kill -9 $(pidof ss-redir)'  # 停止的命令行

## dnsmasq
dnsmasq_cache_size='10240'              # DNS 缓存条目
dnsmasq_cache_time='3600'               # DNS 缓存时间
dnsmasq_log_enable='true'              # 是否记录日志
dnsmasq_log_file='/var/log/dnsmasq.log' # 日志文件路径

## chinadns
chinadns_mutation='false'                # DNS 压缩指针
chinadns_verbose='false'                 # 记录详细日志
chinadns_logfile='/var/log/chinadns.log' # 日志文件路径

## dns
dns_modify='false'           # 直接修改 resolv.conf
dns_remote='8.8.8.8:53'      # 国外 DNS，必须指定端口
dns_direct='114.114.114.114' # 国内 DNS，不能指定端口

## ipts
ipts_rt_tab='100'              # iproute2 路由表名或 ID
ipts_rt_mark='0x2333'          # iproute2 策略路由的标记
ipts_non_snat='false'          # 不设置 SNAT iptables 规则
ipts_intranet=(10.10.5.0/24) # 内网网段，多个请用空格隔开

## opts
opts_ss_netstat="auto"  # 'auto|ss|netstat'，使用哪个端口检测命令

## file
file_gfwlist_txt='/etc/ss-tproxy/gfwlist.txt'   # gfwlist 黑名单文件 (默认规则)
file_gfwlist_ext='/etc/ss-tproxy/gfwlist.ext'   # gfwlist 黑名单文件 (扩展规则)
file_chnroute_txt='/etc/ss-tproxy/chnroute.txt' # chnroute 地址段文件 (chinadns)
file_chnroute_set='/etc/ss-tproxy/chnroute.set' # chnroute 地址段文件 (iptables)

下面是iptables的规则：

# Generated by iptables-save v1.4.21 on Mon Feb 11 00:20:20 2019
*nat
:PREROUTING ACCEPT [11:521]
:INPUT ACCEPT [115:6606]
:OUTPUT ACCEPT [245:17457]
:POSTROUTING ACCEPT [73:5111]
:SSTP_OUT - [0:0]
:SSTP_PRE - [0:0]
:TCPCHAIN - [0:0]
-A PREROUTING -j SSTP_PRE
-A OUTPUT -j SSTP_OUT
-A POSTROUTING -s 10.10.5.0/24 ! -d 10.10.5.0/24 -j MASQUERADE
-A SSTP_OUT -p tcp -j TCPCHAIN
-A SSTP_OUT -d 127.0.0.1/32 -p udp -m udp --dport 53 -j REDIRECT --to-ports 60053
-A SSTP_PRE -s 10.10.5.0/24 -p udp -m udp --dport 53 -m mark ! --mark 0x2333 -j REDIRECT --to-ports 60053
-A SSTP_PRE -s 10.10.5.0/24 -p tcp -j TCPCHAIN
-A TCPCHAIN -d 0.0.0.0/8 -j RETURN
-A TCPCHAIN -d 10.0.0.0/8 -j RETURN
-A TCPCHAIN -d 127.0.0.0/8 -j RETURN
-A TCPCHAIN -d 169.254.0.0/16 -j RETURN
-A TCPCHAIN -d 172.16.0.0/12 -j RETURN
-A TCPCHAIN -d 192.168.0.0/16 -j RETURN
-A TCPCHAIN -d 224.0.0.0/4 -j RETURN
-A TCPCHAIN -d 240.0.0.0/4 -j RETURN
-A TCPCHAIN -d 47.xx.xx.xx/32 -p tcp -m multiport --dports 443 -j RETURN
-A TCPCHAIN -p tcp -j REDIRECT --to-ports 60080
COMMIT
# Completed on Mon Feb 11 00:20:20 2019
# Generated by iptables-save v1.4.21 on Mon Feb 11 00:20:20 2019
*mangle
:PREROUTING ACCEPT [866:57973]
:INPUT ACCEPT [1102:72149]
:FORWARD ACCEPT [2:158]
:OUTPUT ACCEPT [896:1319860]
:POSTROUTING ACCEPT [898:1320018]
:SSTP_OUT - [0:0]
:SSTP_PRE - [0:0]
:UDPCHAIN - [0:0]
-A PREROUTING -j SSTP_PRE
-A OUTPUT -j SSTP_OUT
-A SSTP_OUT -p udp -j UDPCHAIN
-A SSTP_PRE -s 10.10.5.0/24 -p udp -m udp --dport 53 -m mark ! --mark 0x2333 -j ACCEPT
-A SSTP_PRE -s 10.10.5.0/24 -p udp -m mark ! --mark 0x2333 -j UDPCHAIN
-A SSTP_PRE -p udp -m mark --mark 0x2333 -j TPROXY --on-port 60080 --on-ip 127.0.0.1 --tproxy-mark 0x0/0x0
-A UDPCHAIN -d 0.0.0.0/8 -j RETURN
-A UDPCHAIN -d 10.0.0.0/8 -j RETURN
-A UDPCHAIN -d 127.0.0.0/8 -j RETURN
-A UDPCHAIN -d 169.254.0.0/16 -j RETURN
-A UDPCHAIN -d 172.16.0.0/12 -j RETURN
-A UDPCHAIN -d 192.168.0.0/16 -j RETURN
-A UDPCHAIN -d 224.0.0.0/4 -j RETURN
-A UDPCHAIN -d 240.0.0.0/4 -j RETURN
-A UDPCHAIN -d 47.xx.xx.xx/32 -p udp -m multiport --dports 443 -j RETURN
-A UDPCHAIN -j MARK --set-xmark 0x2333/0xffffffff
COMMIT
# Completed on Mon Feb 11 00:20:20 2019

在ss-redir的日志里能看到：

 2019-02-11 00:24:30 INFO: [60080] [udp] cache miss: 8.8.8.8:53 <-> 10.10.5.167:55266
 2019-02-11 00:24:35 INFO: [udp] server receive a packet
 2019-02-11 00:24:35 INFO: [60080] [udp] cache hit: 8.8.8.8:53 <-> 10.10.5.167:55266

请问国外翻回国内，怎么让udp流量通过ss-libev？

RT，目前解决方案是直接用chnroute然后替换了chnroute的表，感觉过于暴力，请问有什么更好地解决方案吗？比如让chnroute的ip才走ss-redir.

如果让udp全局走透明代理呢？

我按照教程安装好之后，发现tcp（http）是正常走透明代理的，但是udp还是走我自己的网络
这个如何设置规则呢？
ps:我的udp程序是aria2下载器

SS-Tproxy 是否会使 iptables的 fwmark功能失效？

我使用

iptables -t mangle -I OUTPUT -p icmp -j MARK --set-mark 0x15
ip rule add fwmark  0x15 table 2
ip route add 0/0 dev wg0 table 2

来实现使ICMP走隧道出去，但是在使用了 ss-tproxy的机器上，这个指令是失效的，数据包并没有成功mark.

大大你好，我经常用 ss-tproxy 中的 chnroute 模式，用这个模式就意味着大部分境外 ip 都要走代理，如果进行 BT/PT 下载 vps 可能就会被封，但大部分 P2P 类下载软件，多使用高端口，所以我想是不是可以自定义需要代理的端口来避免这个问题。openwrt 上的 luci-app-shadowsocks（https://github.com/shadowsocks/luci-app-shadowsocks）提供了此功能，恩山上 hiboy 的 Padavan 固件所内置的 ss 也支持了。我感觉这个功能还是挺重要的，期待大大的进一步开发！大大加油！

强制使用重定向地址的DNS

客户机如果使用了非路由器的DNS，会无法解析到正确地址。可添加以下规则强制使用重定向地址的DNS
iptables -t mangle -A SS-UDP -p udp --dport 53 -j RETURN
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to 192.168.1.1

建议使用PID进行相关应用的启停

目前我是在树莓派上使用ss-tproxy配合create_ap提供wifi全局FQ的。

当我使用ss-tproxy restart的时候，ss-tproxy会将全部的dnsmasq进程都关闭，虽然可以通过更换DHCPD来提供dhcp服务，但是其实只需要ss-tproxy在启动和停止应用的时候，使用pid文件识别就可以解决相关问题了。

dns

设置透明代理后，Docker容器中无法联网

设置监听的内网网段是(192.168.0.0/16 172.17.0.0/16)
现状：
（1）主机可以使用代理
（2）Docker容器中无法使用代理，甚至无法联网

Fedora 29下会出现各种权限错误

更新后发现systemctl start ss-tproxy无法启动
systemctl status ss-tproxy如下
Failed at step EXEC spawning /usr/bin/ss-tproxy: Permission denied
关闭SeLinux可以正常启动
回退到commit 5b393a3a8107c961c91bec2f933e3ed0d309f900可以正常启用

有空我在找找具体原因

遇到 v2ray 客户端报错的问题

我怀疑是 iptables 的问题,帮忙看看这个 iptables 有没有问题,谢谢了!

bash-4.4# iptables-save 
# Generated by iptables-save v1.6.2 on Sun Mar 31 10:25:35 2019
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:SETMARK - [0:0]
:SSTP_OUT - [0:0]
:SSTP_PRE - [0:0]
-A PREROUTING -j SSTP_PRE
-A OUTPUT -j SSTP_OUT
-A SETMARK -d 8.8.8.8/32 -p udp -j MARK --set-xmark 0x2333/0xffffffff
-A SETMARK -m set --match-set gfwlist dst -j MARK --set-xmark 0x2333/0xffffffff
-A SSTP_OUT -p tcp -j SETMARK
-A SSTP_OUT -p udp -j SETMARK
-A SSTP_PRE -s 192.168.2.0/24 -p udp -m udp --dport 53 -m mark ! --mark 0x2333 -j ACCEPT
-A SSTP_PRE -s 192.168.2.0/24 -p tcp -m mark ! --mark 0x2333 -j SETMARK
-A SSTP_PRE -s 192.168.2.0/24 -p udp -m mark ! --mark 0x2333 -j SETMARK
-A SSTP_PRE -p tcp -m mark --mark 0x2333 -j TPROXY --on-port 60080 --on-ip 127.0.0.1 --tproxy-mark 0x0/0x0
-A SSTP_PRE -p udp -m mark --mark 0x2333 -j TPROXY --on-port 60080 --on-ip 127.0.0.1 --tproxy-mark 0x0/0x0
COMMIT
# Completed on Sun Mar 31 10:25:35 2019
# Generated by iptables-save v1.6.2 on Sun Mar 31 10:25:35 2019
*raw
:PREROUTING ACCEPT [10:736]
:OUTPUT ACCEPT [9:442]
COMMIT
# Completed on Sun Mar 31 10:25:35 2019
# Generated by iptables-save v1.6.2 on Sun Mar 31 10:25:35 2019
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:SSTP_OUT - [0:0]
:SSTP_PRE - [0:0]
-A PREROUTING -j SSTP_PRE
-A OUTPUT -j SSTP_OUT
-A SSTP_OUT -d 127.0.0.1/32 -p udp -m udp --dport 53 -j REDIRECT --to-ports 53
-A SSTP_PRE -s 192.168.2.0/24 -p udp -m udp --dport 53 -m mark ! --mark 0x2333 -j REDIRECT --to-ports 53
COMMIT
# Completed on Sun Mar 31 10:25:35 2019
# Generated by iptables-save v1.6.2 on Sun Mar 31 10:25:35 2019
*filter
:INPUT ACCEPT [10:736]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [9:442]
COMMIT
# Completed on Sun Mar 31 10:25:35 2019

https://github.com/lisaac/tproxy-gateway/issues/1

请问有gfwlist版本吗？

请问是否考虑加入大陆地址黑名单模式，即只对大陆地址使用代理？

我这里计划假设从国外往国内的ss代理，所以需求是搭梯子的往国内的代理。

v3-master: 使用 chnroute 模式无法连接国内服务器

使用的是最新的提交：
b0e8dea

以下使用 client 指代非网关机器， server 指代运行 ss-tproxy 的机器。

chnroute 模式

设置成 chnroute 模式，client 运行：

 curl https://news.qq.com

就一直卡住，没有输出，而 server 就正常。

client 和 server 获取国外服务器均正常：

 curl https://www.google.com

global 模式

设置成 global 模式，两台机器获取国内国外服务器都正常。

info

已经使用 /usr/local/bin/ss-tproxy update-chnroute 更新过 chnroute 表。

以下是调试信息：

Client:

#dig news.qq.com

; <<>> DiG 9.14.0 <<>> news.qq.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 517
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;news.qq.com.			IN	A

;; ANSWER SECTION:
news.qq.com.		69	IN	CNAME	https.qq.com.
https.qq.com.		545	IN	A	183.3.226.35

;; Query time: 30 msec
;; SERVER: 168.168.0.14#53(168.168.0.14)
;; WHEN: Tue Apr 09 12:58:29 CST 2019
;; MSG SIZE  rcvd: 76

Server:

# ipset test chnroute 183.3.226.35
183.3.226.35 is in set chnroute.

ss-tproxy.conf:

## mode
#mode='global'
#mode='gfwlist'
mode='chnroute'

## proxy
proxy_tproxy='false'   # 纯TPROXY方式
proxy_server=(xxx01 xxx02)   # 服务器的地址
proxy_dports=''        # 服务器的端口
proxy_tcport='60080'   # TCP 监听端口
proxy_udport='60080'   # UDP 监听端口
proxy_runcmd='systemctl start [email protected]'  # 启动的命令行
proxy_kilcmd='systemctl stop [email protected]'  # 停止的命令行

## dnsmasq
dnsmasq_cache_size='10240'              # DNS 缓存条目
dnsmasq_cache_time='3600'               # DNS 缓存时间
dnsmasq_log_enable='true'              # 是否记录日志
dnsmasq_log_file='/var/log/dnsmasq.log' # 日志文件路径

## chinadns
chinadns_mutation='false'                # DNS 压缩指针
chinadns_verbose='false'                 # 记录详细日志
chinadns_logfile='/var/log/chinadns.log' # 日志文件路径

## dns
dns_modify='false'           # 直接修改 resolv.conf
dns_remote='8.8.8.8:53'      # 国外 DNS，必须指定端口
dns_direct='114.114.114.114' # 国内 DNS，不能指定端口

## ipts
ipts_rt_tab='100'              # iproute2 路由表名或 ID
ipts_rt_mark='0x2333'          # iproute2 策略路由的标记
ipts_non_snat='false'          # 不设置 SNAT iptables 规则
ipts_intranet=(192.168.1.0/24 168.168.0.0/16) # 内网网段，多个请用空格隔开

可以提供个docker镜像吗？

环境安装和配置略复杂，我做了个镜像感觉不是很理想
大神可以提供个官方docker镜像吗？供小白傻瓜化使用你的作品

V2ray 最新版本dokodemo-door已经支持TPROXY了，能否求个TCP的例子。

Vray官方dokodemo-door已经支持linux 的tproxy转发数据，能否求个例子转发tcp数据，目前udp也是网上抄来的。

ip rule add fwmark 0x01/0x01 table 100
ip route add local 0.0.0.0/0 dev lo table 100
iptables -t mangle -N V2RAY
iptables -t mangle -A V2RAY -p udp -j TPROXY --on-port 12345 --tproxy-mark 0x01/0x01
iptables -t mangle -A PREROUTING -j V2RAY
iptables -t mangle -I V2RAY -d 192.168.1.0/24 -j RETURN

期待大大加入ipv6的支持！！！大大加油！！！

怎么实现不同客户端走不同代理？

想实现电视盒子走奈飞线路，其他设备走其他线路

支持ipv6透明代理的一种想法

是不是可以在脚本中判断用户设置的地址是否包含字符‘:’来判断是不是ipv6地址呢？然后在256-260行的地方简单地改变一下，如果是ipv6地址那么就不用return了，因为iptables 只处理ipv4。这是我自己用的脚本，大概是这样的。我不擅长Shell，大佬见笑了。

start_ss_redir(){
    # Start the shadowsocks-redir
    sudo ss-redir -s 2333:1111:5555:2fff:5454:ffff:ffff:2333 -p 23333 \
        -m aes-256-cfb -b 0.0.0.0 -l 65535 -k password -u -v
}

if [ "$1" = "start" ]
then
    sudo iptables -t nat -F PREROUTING    #clear the PREROUTING chain
    sudo iptables -t nat -F OUTPUT        #clear the PREROUTING chain
    sudo iptables -t nat -F SS_TCP        #clear the chain
    sudo iptables -t nat -X SS_TCP        #delete the chain
    
    sudo iptables -t nat -N SS_TCP        # Create new chain
    
    # Ignore shadowsocks server's addresses to avoid loop
    # sudo iptables -t nat -A SS_TCP -p tcp --dport 65535 -j RETURN
    # 我们在用ipv6所以这里不需要
    
    # Ignore LANs addresses to bypass the proxy
    # See Wikipedia and RFC5735 for full list of reserved networks
    sudo iptables -t nat -A SS_TCP -d 0.0.0.0/8 -j RETURN
    sudo iptables -t nat -A SS_TCP -d 10.0.0.0/8 -j RETURN
    sudo iptables -t nat -A SS_TCP -d 127.0.0.0/8 -j RETURN
    sudo iptables -t nat -A SS_TCP -d 169.254.0.0/16 -j RETURN
    sudo iptables -t nat -A SS_TCP -d 172.16.0.0/12 -j RETURN
    sudo iptables -t nat -A SS_TCP -d 192.168.0.0/16 -j RETURN
    sudo iptables -t nat -A SS_TCP -d 224.0.0.0/4 -j RETURN
    sudo iptables -t nat -A SS_TCP -d 240.0.0.0/4 -j RETURN
    
    # Anything else should be redirected to shadowsocks's local port
    sudo iptables -t nat -A SS_TCP -p tcp -j REDIRECT --to-ports 65535
    
    # apply the rules to TCP packages from WLAN Hotspot
    sudo iptables -t nat -A PREROUTING -p tcp -s 10.42.0.0/24 \
                    -j SS_TCP
    # apply the rules to local processes
    sudo iptables -t nat -A OUTPUT -p tcp -j SS_TCP
    
    start_ss_redir;
elif [ "$1" = "clear" ]
then
    sudo iptables -t nat -F PREROUTING    #clear the PREROUTING chain
    sudo iptables -t nat -F OUTPUT        #clear the OUTPUT chain
    sudo iptables -t nat -F SS_TCP        #clear the chain
    sudo iptables -t nat -X SS_TCP        #delete the chain
else
    echo "没有输入参数"
fi

如何让部分内网机子不走代理？

自己添加 hook？有例子吗？

gfwlist失灵，无法更新到ipset，dnsmasq也无法将解析出来的IP添加到ipset

# 列出ipset 已有IP
root@VM-0-9-ubuntu:~# ipset list 
Name: gfwlist
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 600
References: 2
Number of entries: 4
Members:
151.101.0.133
151.101.128.133
151.101.192.133
151.101.64.133

# 更新gfwlist
root@VM-0-9-ubuntu:~# ss-tproxy update-gfwlist 

# 更新完看 ipset 有没有新增IP，结果没有增加
root@VM-0-9-ubuntu:~# ipset list 
Name: gfwlist
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 600
References: 2
Number of entries: 4
Members:
151.101.0.133
151.101.128.133
151.101.192.133
151.101.64.133

# 测试解析是否会自动添加到IPset
root@VM-0-9-ubuntu:~# nslookup -port=60053 google.com  
Server:		127.0.0.1
Address:	127.0.0.1#60053

Non-authoritative answer:
Name:	google.com
Address: 216.58.200.46
Name:	google.com
Address: 2404:6800:4008:801::200e

# 结果也没有增加
root@VM-0-9-ubuntu:~# ipset list  
Name: gfwlist
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 600
References: 2
Number of entries: 4
Members:
151.101.0.133
151.101.128.133
151.101.192.133
151.101.64.133

使用haproxy作为ss-server负载分担器，想使用source ip 做负载分担，怎么做。

报文流向： LAN ----》 iptables-->ss-redir-->haproxy--》 ss-server,
但我发现，haproxy 收到的连接源IP都是本机了，这样就使用不了Haproxy的源IP 负载均衡策略了。

能指点一下有没有什么方法可以ss-redir向haproxy建链的时候，带上代理的真实的内网IP地址？

谢谢

流程过于繁琐…望出 docker 或者优化流程。

昨天折腾了五六个小时…除了网速原因还有就是流程太繁琐了…
ss 不是编译安装还跑不起来…希望优化流程或者出 docker 版本吧，一个新机子，装个 docker 然后直 run 就能当一个网关，我想作者也是希望使用越来越方便的

xt_TPROXY 模块问题

我系统是ubuntu 18.01

运行命令 find /lib/modules/$(uname -r) -type f -name '*.ko*' | grep 'xt_TPROXY'
显示的是 /lib/modules/4.15.0-42-generic/kernel/net/netfilter/xt_TPROXY.ko
一键脚本就会报错
手动部署正常

建议用mount --bind的方式来避免直接修改/etc/resolv.conf

创建/tmp/tproxy/resolv.conf 然后mount --bind /tmp/tproxy/resolv.conf /etc/resolv.conf
结束后umount /etc/resolv.conf即可还原

建议在启动dnsmasq的时候也一并加载一下其自带的配置文件

在linux的软路由上，dnsmasq通常也会作为DHCP server ，其依赖于自带的配置文件/etc/dnsmasq.conf中的配置。但由于ss-tproxy在启动dnsmasq时使用了-C参数，其自带的配置文件/etc/dnsmasq.conf不再会被加载，导致软路由失去了DHCP server的功能。

所以建议在启动dnsmasq的时候也一并加载一下/etc/dnsmasq.conf，通常各大发行版默认的/etc/dnsmasq.conf中全部都是注释，加载一下也不会对原有功能造成冲突。

桥接模式下，内网流量udp正常、tcp协议无法转发。

稍微说明一下，他说的“桥接模式”是这样的，如下图：

ss-tproxy 运行在 bridge 服务器上，这个 bridge 服务器有两个网卡，一个连接出口路由，一个连接内网总线，然后将这两张网卡进行桥接，得到一个逻辑网卡，假设为 br0，br0 网卡通过 DHCP 方式获取路由器分配的 IP 地址信息，然后，这个 bridge 主机能够正常上外网，其它内网主机也能够正常上外网。

但默认情况下，ss-tproxy 并不能正常工作，需要进行几处改动，如下：

加载 br_netfilter 内核模块：modprobe br_netfilter
修改 sysctl.conf 的内核参数，如下：

# 网卡间转发
net.ipv4.ip_forward = 1

# 接收 localnet
net.ipv4.conf.all.route_localnet = 1
net.ipv4.conf.default.route_localnet = 1

# 2 层数据打到 3 层来
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-arptables = 1

修改 ss-tproxy.conf，proxy_tproxy='false'、ipts_non_snat='true'
修改 ss-tproxy，将 -j REDIRECT --to-ports $port 改为 -j DNAT --to-destination 127.0.0.1:$port

请到 README.md 里面查看，里面有关于桥接模式下的透明代理的详细说明

ss-tproxy可用的情况下，ss-tproxy.service失效了

你好
我的操作系统是Ubuntu 18.04
今天貌似更新了下Systemd，ss-tproxy之前一直能用的自启服务突然失效了

systemctl status ss-tproxy

结果如下

● ss-tproxy.service - linux transparent proxy script
   Loaded: loaded (/etc/systemd/system/ss-tproxy.service; disabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2019-02-03 21:04:12 CST; 49s ago
  Process: 6393 ExecStart=/usr/local/bin/ss-tproxy start (code=exited, status=1/FAILURE)
  Process: 6391 ExecStartPre=/bin/bash -c until ping -nq -c1 -W1 114.114.114.114 &>/dev/null; do :; done (code=exited, status=0/SUCCESS)
 Main PID: 6393 (code=exited, status=1/FAILURE)

2月 03 21:04:12 username systemd[1]: Starting linux transparent proxy script...
2月 03 21:04:12 username ss-tproxy[6393]: [ERR]: Require command not found: 'chinadns'
2月 03 21:04:12 username systemd[1]: ss-tproxy.service: Main process exited, code=exited, status=1/FAILURE
2月 03 21:04:12 username systemd[1]: ss-tproxy.service: Failed with result 'exit-code'.
2月 03 21:04:12 username systemd[1]: Failed to start linux transparent proxy script.

可是我安装了ChinaDNS，ss-tproxy check-command没有输出，单独使用ss-tproxy也正常
命令行键入chinadns结果如下

Sun Feb  3 21:16:18 2019 CHNROUTE_FILE not specified, CHNRoute is disabled
Sun Feb  3 21:16:18 2019 chinadns.c:554 bind: Permission denied
Sun Feb  3 21:16:18 2019 Can't bind address 0.0.0.0:53

我制作了一个docker镜像 tcp可以代理，但是udp出现了些问题

使用的ssr 代理
ss-tproxy.conf 配置如下

启动之后

tcp网络的可以

但是运行 udp透明代理的时候

2018-11-12 15:28:05 ERROR: [udp] remote_recv_bind: Address already in use
2018-11-12 15:28:05 ERROR: [udp] remote_recv_bind: Address already in use
2018-11-12 15:28:05 ERROR: [udp] remote_recv_bind: Address already in use

这个是啥很么问题呢? 望解答，谢谢。

iptables v1.8.2 不兼容

在debian 9.9 iptables v1.6.2下运行正常。在debian buster，iptables v1.8.2下启动则会报错。几个表不存在。

archlinux下dnsforwarder无法启动

之前都没问题的，但最近发现dnsforwarder一启动就变僵尸进程了，不知道作者有没有碰到这个问题?

请问ssr配置域名时无法连接是什么问题？

请问ssr配置域名时无法连接是什么问题？使用ip地址却很正常？

ss-tproxy只能运行在linux上么，路由器（openwrt）是不是不可以？

因为我代理服务器(.2)不在路由器(.1)上，我用iptables DNAT透明代理，结果发现DNAT会强行改remote ip。。。
于是我找到这个项目，但我在路由器上运行报错

咨询一下一个小问题

首先，看了你的文章和脚本学习到很多，很感谢！
然后有一个小疑惑：我还是不太理解dnsforwarder在整个作用，搜索了一下，dnsforwarder是"将下游的 UDP 协议的 DNS 查询转换成 TCP 协议的 DNS 查询后发送到上游服务器"的作用。但是文中看起来，dnsforwarder好像只是一个DNS 缓存和加速的用途，这是不是可以用Dnsmasq来取代？用dnsforwarder把DNS查询转成TCP，再从本机的chinadns转出去，会不会多了一步？

在tun2socks模式下 Push 节点信息会报错

在使用 tun2socks 模式下，Shadowsocks-mu-py拉取json报错 JSON ValueError: Expecting property name: line 1 column 2 (char 1)

而访问其他被墙网站都是正常的，请问这个是什么原因？

想要使用tcponly，可以给我一份v2版吗？

你好！我现在在openwrt路由器里面有个socks5的代理在运行，我想把它变成透明代理，但是这个代理只支持tcp，可以给我一份v2吗？谢谢！

dnsforwarder [stopped]

Cannot run properly. Need Help.

$ sudo ss-tproxy restart
[sudo] paul 的密码：
ss-redir [stopped]
ss-tunnel [stopped]
chinadns [stopped]
dnsforwarder [stopped]

ss-redir [running]
ss-tunnel [running]
chinadns [running]
dnsforwarder [stopped]

配置有误

// as ss-redir
{
"port": 60080,
"protocol": "dokodemo-door",
"settings": {
"network": "tcp,udp",
"followRedirect": true,
"domainOverride": ["quic"]
}
},
// as ss-tunnel
{
"port": 60053,
"protocol": "dokodemo-door",
"settings": {
"address": "8.8.8.8",
"port": 53,
"network": "udp",
"followRedirect": false
}
},

这个配置settings中漏了一个参数："domainOverride": ["tls","http"],

ss-tproxy start 提示如下

dnsmasq: bad option at line 6 of /dev/fd/63
RTNETLINK answers: File exists
mount: warning: /etc/resolv.conf seems to be mounted read-write.
mode: tproxy_gfwlist
ssr-redir: [stopped]
ssr-tunnel: [stopped]
dnsmasq: [stopped]

首谢感谢您的无私分享，我有两个疑问想与您探讨一下！

第一这个能不能直接安装在国内的服务器上，因为现在国内很多区域性的问题，这样用户通过VPN或SS连接国内的服务器，就充当了一级的网关的角色！
第二有没有可以，将所有的dns的请求，全部转发到网关的53上，这样就不用管Client怎么设置dns,都可以正确使用了！

v2ray自带路由和dns iproute2, ipset, chinadns, 还必要么？

是否可以支持goflyway

这款软件能否支持goflyway呢

关于使用SS作为转发发现的一个问题

首先，感谢作者提供这样一个脚本，真的很方便。
我接下来的问题可能和脚本是无关的，但如果作者有时间的话大家可以一起探讨下。

环境介绍

由多台服务器使用公网打通Wireguard后的局域网
使用 shadowsocks-libev
系统：CentOS 7 64bit 4.12.1

服务器介绍

Aliyun Beijing
RU Server (10.3.0.1/32, 10.3.100.1/32)
De Server (10.3.100.2/32, 10.3.101.1/32)

脚本使用Chnroute + SS方式，并且加了所有的服务器公网IP到Iptables表让他们不走ss-tproxy

proxy_tproxy='false'   # 纯TPROXY方式
proxy_server='10.3.100.2'   # 服务器的地址
proxy_tcport='60080'   # TCP 监听端口
proxy_udport='60080'   # UDP 监听端口
proxy_runcmd='(ss-redir -s 10.3.100.2 -p * -m * -k *-b 0.0.0.0 -l 60080 --no-delay --reuse-port -u -v  </dev/null &>>/var/log/ss-redir.log &)'  # 启动的命令行
proxy_kilcmd='kill -9 $(pidof ss-redir)'  # 停止的命令

该模式使用正常，但是我将10.3.100.2换成10.3.101.1（同一台服务器）ss-tproxy就工作不正常。具体的log如下

cat chinadns.log 
Fri Nov 23 00:49:33 2018 request ip.sb
Fri Nov 23 00:49:33 2018 request ip.sb
Fri Nov 23 00:49:33 2018 response ip.sb from 114.114.114.114:53 - 47.52.68.57, filter
Fri Nov 23 00:49:33 2018 response ip.sb from 114.114.114.114:53 - pass
Fri Nov 23 00:49:38 2018 request ip.sb
Fri Nov 23 00:49:38 2018 response ip.sb from 114.114.114.114:53 - 47.52.68.57, filter
Fri Nov 23 00:49:43 2018 request ip.sb
Fri Nov 23 00:49:43 2018 response ip.sb from 114.114.114.114:53 - Fri Nov 23 00:51:05 2018 request ip.sb
Fri Nov 23 00:51:05 2018 request ip.sb
Fri Nov 23 00:51:05 2018 response ip.sb from 114.114.114.114:53 - 47.52.68.57, filter
Fri Nov 23 00:51:05 2018 response ip.sb from 114.114.114.114:53 - pass
Fri Nov 23 00:51:10 2018 request ip.sb
Fri Nov 23 00:51:10 2018 response ip.sb from 114.114.114.114:53 - 47.52.68.57, filter
Fri Nov 23 00:51:15 2018 request ip.sb
Fri Nov 23 00:51:15 2018 response ip.sb from 114.114.114.114:53 - Fri Nov 23 00:59:51 2018 request ip.sb
Fri Nov 23 00:59:51 2018 request ip.sb
Fri Nov 23 00:59:51 2018 response ip.sb from 114.114.114.114:53 - 47.52.68.57, filter
Fri Nov 23 00:59:51 2018 response ip.sb from 114.114.114.114:53 - pass
Fri Nov 23 00:59:56 2018 request ip.sb
Fri Nov 23 00:59:56 2018 response ip.sb from 114.114.114.114:53 - 47.52.68.57, filter
Fri Nov 23 01:00:01 2018 request ip.sb

此时德国服务器上并没有收到DNS请求。

2018-11-23 00:38:54 INFO: [udp] server receive a packet
 2018-11-23 00:38:54 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:38:59 INFO: [udp] server receive a packet
 2018-11-23 00:38:59 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:39:04 INFO: [udp] server receive a packet
 2018-11-23 00:39:04 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:39:14 INFO: [udp] server receive a packet
 2018-11-23 00:39:14 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:39:19 INFO: [udp] server receive a packet
 2018-11-23 00:39:19 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:39:30 INFO: [udp] server receive a packet
 2018-11-23 00:39:30 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:39:35 INFO: [udp] server receive a packet
 2018-11-23 00:39:35 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:39:40 INFO: [udp] server receive a packet
 2018-11-23 00:39:40 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:40:47 INFO: [udp] server receive a packet
 2018-11-23 00:40:47 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:40:52 INFO: [udp] server receive a packet
 2018-11-23 00:40:52 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:08 INFO: [udp] server receive a packet
 2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:08 INFO: [udp] server receive a packet
 2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:08 INFO: [udp] server receive a packet
 2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:08 INFO: [udp] server receive a packet
 2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:08 INFO: [udp] server receive a packet
 2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:08 INFO: [udp] server receive a packet
 2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:08 INFO: [udp] server receive a packet
 2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:08 INFO: [udp] server receive a packet
 2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:08 INFO: [udp] server receive a packet
 2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:08 INFO: [udp] server receive a packet
 2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:08 INFO: [udp] server receive a packet
 2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:13 INFO: [udp] server receive a packet
 2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:13 INFO: [udp] server receive a packet
 2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:13 INFO: [udp] server receive a packet
 2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:13 INFO: [udp] server receive a packet
 2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:13 INFO: [udp] server receive a packet
 2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:13 INFO: [udp] server receive a packet
 2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:13 INFO: [udp] server receive a packet
 2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:13 INFO: [udp] server receive a packet
 2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:13 INFO: [udp] server receive a packet
 2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:13 INFO: [udp] server receive a packet
 2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
 2018-11-23 00:41:13 INFO: [udp] server receive a packet
 2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754

这是阿里云上的ss-redir的log。

[Question] multiple proxy_server

How to write multiple servers, I try to follow the instruction, set 2 proxy server in configure file but it not working.

mode

mode='global'
#mode='gfwlist'
#mode='chnroute'

proxy

proxy_tproxy='true' # 纯TPROXY方式
proxy_server=(a.net b.net) # 服务器的地址
proxy_tcport='1080' # TCP 监听端口
proxy_udport='1080' # UDP 监听端口

使用自建DNS解析流量全部走代理

在PI上安装作为网关工作在主路由下
ChinaDNS国内DNS 设置为114.114.114.114 工作正常
修改为同一局域网下的自建DNS（AdGuardHome 单独使用正常）所有流量走代理

内网端口映射到公网失败

ip rule add fwmark 0x01/0x01 table 100
ip route add local 0.0.0.0/0 dev lo table 100
iptables -t mangle -N V2RAY
iptables -t mangle -I V2RAY -d 192.168.1.0/24 -j RETURN
iptables -t mangle -I V2RAY -d 127.0.0.1/32 -j RETURN
iptables -t mangle -A V2RAY -p udp -j TPROXY --on-port 12345 --tproxy-mark 0x01/0x01
iptables -t mangle -A V2RAY -p tcp -j TPROXY --on-port 12345 --tproxy-mark 0x01/0x01
iptables -t mangle -A PREROUTING -j V2RAY

按照上面例子可以实现V2RAY TCP和UDP全部走tproxy，但是端口映射会失败。

我感觉好像所有流量去了TPROXY之后都送给了dokodemo-door才会这样，有没有什么办法不送某个端口流量给dokodemo-door.

我v2ray地址上的某个端口映射到了公网，用上面的例子无法成功映射。

求方法让私网映射端口工作正常。

这里几个清理 iptables 的命令是不是太暴力了？

ss-tproxy/ss-tproxy

Line 397 in ca6dcc8

iptables -t nat -F OUTPUT

    iptables -t nat -F OUTPUT
    iptables -t nat -F PREROUTING

    iptables -t mangle -F OUTPUT
    iptables -t mangle -F PREROUTING

如果原来有规则的话，会被这几个指令清掉吧？是不是自己 new 一条链比较好？

功能增强：用户自定义udp转发的端口

大概看了下脚本，tproxy应该是全部端口转发了吧，有时候只需要转发制定的端口就够了。
最近入了台软路由，打算直接上Arch Linux当路由，到时候ss-tproxy可能会派上用场，嘿嘿。

请问chnroute模式下的chinadns有替代品吗？

解析mail.qq.com解析到海外了，log如下

Thu Apr 25 18:44:28 2019 response mail.qq.com from 223.5.5.5:53 - 14.18.245.237, delay
Thu Apr 25 18:44:28 2019 response mail.qq.com from 8.8.8.8:53 - 103.7.30.100, 203.205.128.111, pass