设备通过代理，可以访问国内网站，外网没有响应

zfl9 / ss-tproxy

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

GNU Affero General Public License v3.0

2.21k stars 437 forks source link

设备通过代理，可以访问国内网站，外网没有响应 #115

Closed ifaws closed 4 years ago

ifaws commented 4 years ago

代理: Raspberrypi 4 - Raspbian buster lite - V2ray - ss-tproxy ip:192.168.1.8 - gateway:192.168.1.1 - mask:255.255.255.0 Issues: 局域网设备通过树莓派代理，可访问国内网站，外网无响应 Log: root@raspberrypi:/home/pi# ss-tproxy status mode: chnroute pxy/tcp: [running] pxy/udp: [running] dnsmasq: [running] chinadns: [running]

root@raspberrypi:/home/pi# systemctl status v2ray ● v2ray.service - V2Ray Service Loaded: loaded (/etc/systemd/system/v2ray.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2020-02-07 10:43:53 CST; 6min ago Main PID: 567 (v2ray) Tasks: 11 (limit: 4915) Memory: 19.6M CGroup: /system.slice/v2ray.service └─567 /usr/bin/v2ray/v2ray -config /etc/v2ray/config.json

root@raspberrypi:/home/pi# curl -x socks5://127.0.0.1:1080 baidu.com curl: (7) Failed to receive SOCKS5 connect request ack. root@raspberrypi:/home/pi# curl -x socks5://127.0.0.1:1080 google.com curl: (6) Could not resolve host: www.google.com

root@raspberrypi:/home/pi# dig @127.0.0.1 -p65353 baidu.com ; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> @127.0.0.1 -p65353 baidu.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42486 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.baidu.com. IN A

;; ANSWER SECTION: www.baidu.com. 723 IN CNAME www.a.shifen.com. www.a.shifen.com. 153 IN A 61.135.169.121 www.a.shifen.com. 153 IN A 61.135.169.125

;; Query time: 8 msec ;; SERVER: 127.0.0.1#65353(127.0.0.1) ;; WHEN: Fri Feb 07 10:53:27 CST 2020 ;; MSG SIZE rcvd: 101

root@raspberrypi:/home/pi# dig @127.0.0.1 -p65353 google.com ; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> @127.0.0.1 -p65353 www.google.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached

root@raspberrypi:/home/pi# chinadns-ng -v 2020-02-07 10:56:26 INF: [main] local listen addr: 127.0.0.1#65353 2020-02-07 10:56:26 INF: [main] chinadns server#1: 114.114.114.114#53 2020-02-07 10:56:26 INF: [main] trustdns server#1: 8.8.8.8#53 2020-02-07 10:56:26 INF: [main] ipset ip4 setname: chnroute 2020-02-07 10:56:26 INF: [main] ipset ip6 setname: chnroute6 2020-02-07 10:56:26 INF: [main] dns query timeout: 3 seconds 2020-02-07 10:56:26 INF: [main] core judgment mode: fast mode 2020-02-07 10:56:26 INF: [main] print the verbose running log 2020-02-07 10:56:26 ERR: [main] failed to bind address to socket: (98) Address already in use

配置文件 ss-tproxy:

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

## ipv4/6
ipv4='true'
ipv6='false' 

## tproxy
tproxy='false'

## tcponly
tcponly='false'

## selfonly
selfonly='false'

## proxy
proxy_svraddr4=(1.2.3.4)
proxy_svraddr6=()
proxy_svrport='20124'
proxy_tcpport='12345'
proxy_udpport='12345'
proxy_startcmd='systemctl start v2ray'
proxy_stopcmd='systemctl stop v2ray' 

## dns
dns_direct='114.114.114.114' 
dns_direct6='240C::6666' 
dns_remote='8.8.8.8#53'
dns_remote6='2001:4860:4860::8888#53' 

## dnsmasq
dnsmasq_bind_port='60053' 
dnsmasq_cache_size='4096'
dnsmasq_cache_time='3600' 
dnsmasq_log_enable='false' 
dnsmasq_log_file='/var/log/dnsmasq.log'
dnsmasq_conf_dir=() 
dnsmasq_conf_file=() 
dnsmasq_conf_string=()

## chinadns
chinadns_bind_port='65353' 
chinadns_timeout='3' 
chinadns_repeat='1' 
chinadns_fairmode='false' 
chinadns_gfwlist_mode='false'  
chinadns_noip_as_chnip='false'
chinadns_verbose='false'
chinadns_logfile='/var/log/chinadns.log'
chinadns_privaddr4=() 
chinadns_privaddr6=() 

## dns2tcp
dns2tcp_bind_port='65454' 
dns2tcp_verbose='false' 
dns2tcp_logfile='/var/log/dns2tcp.log'

## ipts
ipts_if_lo='lo' 
ipts_rt_tab='233'
ipts_rt_mark='0x2333'
ipts_set_snat='false' 
ipts_set_snat6='false' 
ipts_reddns_onstop='true' 
ipts_proxy_dst_port='1:65535' 

## opts
opts_ss_netstat='auto' 
opts_ping_cmd_to_use='auto'
opts_hostname_resolver='auto' 
opts_overwrite_resolv='false'
opts_ip_for_check_net='114.114.114.114' 

## file
file_gfwlist_txt='/etc/ss-tproxy/gfwlist.txt' 
file_gfwlist_ext='/etc/ss-tproxy/gfwlist.ext' 
file_ignlist_ext='/etc/ss-tproxy/ignlist.ext'  
file_chnroute_set='/etc/ss-tproxy/chnroute.set'
file_chnroute6_set='/etc/ss-tproxy/chnroute6.set' 
file_dnsserver_pid='/etc/ss-tproxy/.dnsserver.pid'

v2ray:

{
  "inbounds": [
    {
     "tag":"transparent",
     "port": 12345,
     "protocol": "dokodemo-door",
     "settings": {
       "network":"tcp,udp",
       "followRediect":true
     },
     "sniffing":{
       "enabled":true,
        "destOverride":["http","tls"]
     },
   "streamSettings":{
     "sockopt":{
       "tproxy":"tproxy"
     }
   }
    },
 {
    "port":1080,
    "protocol":"socks",
    "sniffing":{
        "enabled":true,
        "destOverride":["http","tls"]
    },
    "settings":{
        "auth":"noauth"
    }
 }
  ],

    "outbounds": [
    {
        "tag":"proxy",
     "protocol":"vmess",
         "settings":{
                 "vnext":[
                      {
            "address":"1.2.3.4",
            "port":20124,
            "users":[
                {
                 "id":"UUID",
                 "alterId":64
                     }
             ]
              }
              ]
              },
        "mux":{
            "enabled":true
        }
    }
    ]
  }

zfl9 commented 4 years ago

ifaws commented 4 years ago

按上图，已在/etc/v2ray/config.json中加入"listen":"0.0.0.0“代码，reboot设备后，情况没有改善

zfl9 commented 4 years ago

你在ss-tproxy.conf里面配置的tproxy=false，然而又在v2ray里面配置了tproxy方式。能代理就怪了。

ifaws commented 4 years ago

已将ss-tproxy.conf里的tproxy=false 改为 true，重启设备后依旧外国网站不通，v2ray的outbounds配置确认无误，因为先配置了v2ray，测试google通了以后才继续配置的ss-tproxy。是否与chvinadns-ng -v打印的failed to bind address to socket: (98) Address already in use有关？

zfl9 commented 4 years ago

chinadns-ng -v 和你这个问题没有半毛钱关系。你应该去看日志！请再次阅读readme最后一段，再说一次，请看代理软件v2、dnsmasq、chinadns-ng的日志（请打开ss-tproxy.conf里面的各种log_verbose开关）。

zfl9 commented 4 years ago

光一句不能代理，有太多种原因了，不看日志鬼知道什么问题。

ifaws commented 4 years ago

好的好的，我检查日志记录

ifaws commented 4 years ago

运行dig命令后，查看了/var/log/chinadns.log

2020-02-07 12:29:22 INF: [handle_local_packet] query [www.baidu.com] from 127.0.0.1#48339
2020-02-07 12:29:22 INF: [handle_remote_packet] reply [www.baidu.com] from 114.114.114.114#53, result: accept
2020-02-07 12:29:32 INF: [handle_local_packet] query [www.google.com] from 127.0.0.1#41163
2020-02-07 12:29:32 INF: [handle_remote_packet] reply [www.google.com] from 114.114.114.114#53, result: filter
2020-02-07 12:29:35 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 25
2020-02-07 12:29:37 INF: [handle_local_packet] query [www.google.com] from 127.0.0.1#41163
2020-02-07 12:29:37 INF: [handle_remote_packet] reply [www.google.com] from 114.114.114.114#53, result: filter
2020-02-07 12:29:40 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 26
2020-02-07 12:29:42 INF: [handle_local_packet] query [www.google.com] from 127.0.0.1#41163
2020-02-07 12:29:42 INF: [handle_remote_packet] reply [www.google.com] from 114.114.114.114#53, result: filter
2020-02-07 12:29:45 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 27

zfl9 commented 4 years ago

显然8.8.8.8上游超时了，继续看v2ray的日志，要沿着数据的走向看日志。

ifaws commented 4 years ago

同样是dig命令后，观察v2ray的error.log日志，有如下输出，显示无法获取目标地址,奇怪

2020/02/07 12:50:38 [Debug] v2ray.com/core/app/proxyman/inbound: creating stream worker on 0.0.0.0:12345
2020/02/07 12:50:38 [Debug] v2ray.com/core/app/proxyman/inbound: creating stream worker on 0.0.0.0:1080
2020/02/07 12:50:38 [Info] v2ray.com/core/transport/internet/tcp: listening TCP on 0.0.0.0:12345
2020/02/07 12:50:38 [Info] v2ray.com/core/transport/internet/udp: listening UDP on 0.0.0.0:12345
2020/02/07 12:50:38 [Info] v2ray.com/core/transport/internet/tcp: listening TCP on 0.0.0.0:1080
2020/02/07 12:50:38 [Warning] v2ray.com/core: V2Ray 4.22.1 started
2020/02/07 12:50:50 [Debug] [351108695] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:50:50 [Info] [351108695] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:50:56 [Debug] [1188929081] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:50:56 [Info] [1188929081] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:50:56 [Debug] [2727490863] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:50:56 [Info] [2727490863] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:50:56 [Debug] [2637517469] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033

zfl9 commented 4 years ago

完整输出发来

ps -ef | grep v2ray

ifaws commented 4 years ago

root@raspberrypi:/home/pi# ps -ef | grep v2ray

root       564     1    0  12:50    ?     00:00:00 /usr/bin/v2ray/v2ray -config /etc/v2ray/config.json
root       914   888  0  13:14   pts/0    00:00:00 grep v2ray

root@raspberrypi:/home/pi# cat /var/log/v2ray/error.log

2020/02/07 12:48:51 [Debug] v2ray.com/core/app/log: Logger started
2020/02/07 12:48:51 [Debug] v2ray.com/core/app/proxyman/inbound: creating stream worker on 0.0.0.0:12345
2020/02/07 12:48:51 [Debug] v2ray.com/core/app/proxyman/inbound: creating stream worker on 0.0.0.0:1080
2020/02/07 12:48:51 [Info] v2ray.com/core/transport/internet/tcp: listening TCP on 0.0.0.0:12345
2020/02/07 12:48:51 [Info] v2ray.com/core/transport/internet/udp: listening UDP on 0.0.0.0:12345
2020/02/07 12:48:51 [Info] v2ray.com/core/transport/internet/tcp: listening TCP on 0.0.0.0:1080
2020/02/07 12:48:51 [Warning] v2ray.com/core: V2Ray 4.22.1 started
2020/02/07 12:48:59 [Debug] [3350546447] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:50022
2020/02/07 12:48:59 [Info] [3350546447] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:49:08 [Debug] [4027072880] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:50022
2020/02/07 12:49:08 [Info] [4027072880] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:49:13 [Debug] [1499374663] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:50022
2020/02/07 12:49:13 [Info] [1499374663] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:49:18 [Debug] [112341433] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:50022
2020/02/07 12:49:18 [Info] [112341433] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:50:19 [Debug] v2ray.com/core/app/log: Logger closing
2020/02/07 12:50:38 [Debug] v2ray.com/core/app/log: Logger started
2020/02/07 12:50:38 [Debug] v2ray.com/core/app/proxyman/inbound: creating stream worker on 0.0.0.0:12345
2020/02/07 12:50:38 [Debug] v2ray.com/core/app/proxyman/inbound: creating stream worker on 0.0.0.0:1080
2020/02/07 12:50:38 [Info] v2ray.com/core/transport/internet/tcp: listening TCP on 0.0.0.0:12345
2020/02/07 12:50:38 [Info] v2ray.com/core/transport/internet/udp: listening UDP on 0.0.0.0:12345
2020/02/07 12:50:38 [Info] v2ray.com/core/transport/internet/tcp: listening TCP on 0.0.0.0:1080
2020/02/07 12:50:38 [Warning] v2ray.com/core: V2Ray 4.22.1 started
2020/02/07 12:50:50 [Debug] [351108695] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:50:50 [Info] [351108695] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:50:56 [Debug] [1188929081] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:50:56 [Info] [1188929081] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:50:56 [Debug] [2727490863] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:50:56 [Info] [2727490863] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:50:56 [Debug] [2637517469] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:50:56 [Info] [2637517469] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:01 [Debug] [3779932658] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:01 [Info] [3779932658] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:01 [Debug] [3254261072] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:01 [Info] [3254261072] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:06 [Debug] [3055854904] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:06 [Info] [3055854904] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:06 [Debug] [4208141519] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:06 [Info] [4208141519] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:06 [Debug] [906834498] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:06 [Info] [906834498] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:11 [Debug] [4064596353] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:11 [Info] [4064596353] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:11 [Debug] [3478636172] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:11 [Info] [3478636172] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:16 [Debug] [3763648706] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:16 [Info] [3763648706] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:16 [Debug] [3079328459] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:16 [Info] [3079328459] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:21 [Debug] [2897295705] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:21 [Info] [2897295705] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:26 [Debug] [2822071976] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:26 [Info] [2822071976] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:26 [Debug] [276214691] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:26 [Info] [276214691] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:31 [Debug] [1164281540] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:31 [Info] [1164281540] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:31 [Debug] [2634445860] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:31 [Info] [2634445860] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:36 [Debug] [2119633513] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:36 [Info] [2119633513] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:36 [Debug] [1118771146] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:36 [Info] [1118771146] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:41 [Debug] [95140293] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:41 [Info] [95140293] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:41 [Debug] [762199574] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:41 [Info] [762199574] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:46 [Debug] [1311499280] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:46 [Info] [1311499280] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:51:51 [Debug] [1581162674] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:51:51 [Info] [1581162674] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination
2020/02/07 12:53:19 [Debug] [1933650086] v2ray.com/core/proxy/dokodemo: processing connection from: 192.168.1.8:35033
2020/02/07 12:53:19 [Info] [1933650086] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/dokodemo: unable to get destination

zfl9 commented 4 years ago

去v2ray问下吧

ifaws commented 4 years ago

好的~感谢解答

ifaws commented 4 years ago

似乎找到问题了，是V2Ray的Dokodemo-door有问题，检查端口监听，发现V2Ray只监听了TCP6的代理端口(12345,1080)，搜索了github上相同的V2ray Dokodemo-door问题，均未得到解决。

root@raspberrypi:/home/pi# netstat -an|grep LISTEN
tcp        0      0 0.0.0.0:60053           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN     
tcp6       0      0 :::60053                :::*                    LISTEN     
tcp6       0      0 :::53                   :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 :::1080                 :::*                    LISTEN     
tcp6       0      0 :::12345                :::*                    LISTEN     
tcp6       0      0 ::1:6010                :::*                    LISTEN     
unix  2      [ ACC ]     SEQPACKET  LISTENING     8472     /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     15645    /run/user/1000/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     15651    /run/user/1000/gnupg/S.gpg-agent.browser
unix  2      [ ACC ]     STREAM     LISTENING     11555    /run/avahi-daemon/socket
unix  2      [ ACC ]     STREAM     LISTENING     15654    /run/user/1000/gnupg/S.gpg-agent.extra
unix  2      [ ACC ]     STREAM     LISTENING     15656    /run/user/1000/gnupg/S.dirmngr
unix  2      [ ACC ]     STREAM     LISTENING     11560    /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     15658    /run/user/1000/gnupg/S.gpg-agent.ssh
unix  2      [ ACC ]     STREAM     LISTENING     15660    /run/user/1000/gnupg/S.gpg-agent
unix  2      [ ACC ]     STREAM     LISTENING     11564    /run/thd.socket
unix  2      [ ACC ]     STREAM     LISTENING     7807     /run/systemd/fsck.progress
unix  2      [ ACC ]     STREAM     LISTENING     12703    /var/run/dhcpcd.sock
unix  2      [ ACC ]     STREAM     LISTENING     12705    /var/run/dhcpcd.unpriv.sock
unix  2      [ ACC ]     STREAM     LISTENING     8430     /run/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     8436     /run/systemd/journal/stdout

tankren commented 4 years ago

你的12345端口在UDP上没有开启监听我的netstat有两条60080 但是咱们的v2ray配置差不多所以不知道你的问题在哪里重新安装v2ray试试或者换个linux发行版

tankren commented 4 years ago

root@raspberrypi:/home/pi# netstat -an|grep LISTEN
tcp        0      0 0.0.0.0:60053           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN     
tcp6       0      0 :::60053                :::*                    LISTEN     
tcp6       0      0 :::53                   :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 :::1080                 :::*                    LISTEN     
tcp6       0      0 :::12345                :::*                    LISTEN     
tcp6       0      0 ::1:6010                :::*                    LISTEN     
unix  2      [ ACC ]     SEQPACKET  LISTENING     8472     /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     15645    /run/user/1000/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     15651    /run/user/1000/gnupg/S.gpg-agent.browser
unix  2      [ ACC ]     STREAM     LISTENING     11555    /run/avahi-daemon/socket
unix  2      [ ACC ]     STREAM     LISTENING     15654    /run/user/1000/gnupg/S.gpg-agent.extra
unix  2      [ ACC ]     STREAM     LISTENING     15656    /run/user/1000/gnupg/S.dirmngr
unix  2      [ ACC ]     STREAM     LISTENING     11560    /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     15658    /run/user/1000/gnupg/S.gpg-agent.ssh
unix  2      [ ACC ]     STREAM     LISTENING     15660    /run/user/1000/gnupg/S.gpg-agent
unix  2      [ ACC ]     STREAM     LISTENING     11564    /run/thd.socket
unix  2      [ ACC ]     STREAM     LISTENING     7807     /run/systemd/fsck.progress
unix  2      [ ACC ]     STREAM     LISTENING     12703    /var/run/dhcpcd.sock
unix  2      [ ACC ]     STREAM     LISTENING     12705    /var/run/dhcpcd.unpriv.sock
unix  2      [ ACC ]     STREAM     LISTENING     8430     /run/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     8436     /run/systemd/journal/stdout

老哥你这个问题解决了吗，我的症状跟你一样，但是只有在路由器里面设置网关和DNS为ss-tproxy的IP才会这样，如果本机测试，一点问题都没有，如果LAN内其它主机手动设置网关和DNS为ss-tproxy服务器，一开始还能用一会，后面就突然不行了，dnsmasq和chinadns-ng自己stop，restart能成功，但是日志里面的报错跟你一样，这种情况下，国内域名访问没问题，本机curl测试Google会提示无法解析。试了debian和centos都一样，迷惑了。

ifaws commented 4 years ago

root@raspberrypi:/home/pi# netstat -an|grep LISTEN
tcp        0      0 0.0.0.0:60053           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN     
tcp6       0      0 :::60053                :::*                    LISTEN     
tcp6       0      0 :::53                   :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 :::1080                 :::*                    LISTEN     
tcp6       0      0 :::12345                :::*                    LISTEN     
tcp6       0      0 ::1:6010                :::*                    LISTEN     
unix  2      [ ACC ]     SEQPACKET  LISTENING     8472     /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     15645    /run/user/1000/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     15651    /run/user/1000/gnupg/S.gpg-agent.browser
unix  2      [ ACC ]     STREAM     LISTENING     11555    /run/avahi-daemon/socket
unix  2      [ ACC ]     STREAM     LISTENING     15654    /run/user/1000/gnupg/S.gpg-agent.extra
unix  2      [ ACC ]     STREAM     LISTENING     15656    /run/user/1000/gnupg/S.dirmngr
unix  2      [ ACC ]     STREAM     LISTENING     11560    /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     15658    /run/user/1000/gnupg/S.gpg-agent.ssh
unix  2      [ ACC ]     STREAM     LISTENING     15660    /run/user/1000/gnupg/S.gpg-agent
unix  2      [ ACC ]     STREAM     LISTENING     11564    /run/thd.socket
unix  2      [ ACC ]     STREAM     LISTENING     7807     /run/systemd/fsck.progress
unix  2      [ ACC ]     STREAM     LISTENING     12703    /var/run/dhcpcd.sock
unix  2      [ ACC ]     STREAM     LISTENING     12705    /var/run/dhcpcd.unpriv.sock
unix  2      [ ACC ]     STREAM     LISTENING     8430     /run/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     8436     /run/systemd/journal/stdout

用netstat -tulpn命令查看的话，对于TCP连接，由于V2RAY同时监听了ipv4和ipv6，netstat会只显示ipv6部分。对于UDP连接，state列并不会显示LISTEN状态，但可以看到进程绑定的端口，同样由于V2RAY同时绑定了ipv4和ipv6，所以它也只显示了ipv6部分的绑定端口。

问题是解决了，但可能不适用你的情况，建议你提供SS-tproxy配置、v2ray配置、局域网拓扑的详细信息，才好解决问题。

但你提到在路由器中，将路由器的网关和DNS设置为代理服务器的IP，这有问题，因为路由器作为出口，网关应当是通过PPPoE拨号向ISP提供商获取的才对。我是把代理服务器连接在局域网的交换机上，交换机再和路由器连接，客户端从交换机接入的局域网，然后客户端的网关和DNS指向代理服务器就可以科学上网了，等于是客户端的流量从代理服务器那绕了一圈，也尝试过将代理服务器直接插在路由器上，这时客户端是无法联网的，可能是由于我的路由器几个LAN口并不是工作在交换状态。所以如果你配置好代理服务器以后，而且代理服务器本机测试dig google.com正常，那很有可能是局域网内连接的问题。

tankren commented 4 years ago

似乎找到问题了，是V2Ray的Dokodemo-door有问题，检查端口监听，发现V2Ray只监听了TCP6的代理端口(12345,1080)，搜索了github上相同的V2ray Dokodemo-door问题，均未得到解决。
root@raspberrypi:/home/pi# netstat -an|grep LISTEN
tcp        0      0 0.0.0.0:60053           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN     
tcp6       0      0 :::60053                :::*                    LISTEN     
tcp6       0      0 :::53                   :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 :::1080                 :::*                    LISTEN     
tcp6       0      0 :::12345                :::*                    LISTEN     
tcp6       0      0 ::1:6010                :::*                    LISTEN     
unix  2      [ ACC ]     SEQPACKET  LISTENING     8472     /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     15645    /run/user/1000/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     15651    /run/user/1000/gnupg/S.gpg-agent.browser
unix  2      [ ACC ]     STREAM     LISTENING     11555    /run/avahi-daemon/socket
unix  2      [ ACC ]     STREAM     LISTENING     15654    /run/user/1000/gnupg/S.gpg-agent.extra
unix  2      [ ACC ]     STREAM     LISTENING     15656    /run/user/1000/gnupg/S.dirmngr
unix  2      [ ACC ]     STREAM     LISTENING     11560    /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     15658    /run/user/1000/gnupg/S.gpg-agent.ssh
unix  2      [ ACC ]     STREAM     LISTENING     15660    /run/user/1000/gnupg/S.gpg-agent
unix  2      [ ACC ]     STREAM     LISTENING     11564    /run/thd.socket
unix  2      [ ACC ]     STREAM     LISTENING     7807     /run/systemd/fsck.progress
unix  2      [ ACC ]     STREAM     LISTENING     12703    /var/run/dhcpcd.sock
unix  2      [ ACC ]     STREAM     LISTENING     12705    /var/run/dhcpcd.unpriv.sock
unix  2      [ ACC ]     STREAM     LISTENING     8430     /run/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     8436     /run/systemd/journal/stdout
老哥你这个问题解决了吗，我的症状跟你一样，但是只有在路由器里面设置网关和DNS为ss-tproxy的IP才会这样，如果本机测试，一点问题都没有，如果LAN内其它主机手动设置网关和DNS为ss-tproxy服务器，一开始还能用一会，后面就突然不行了，dnsmasq和chinadns-ng自己stop，restart能成功，但是日志里面的报错跟你一样，这种情况下，国内域名访问没问题，本机curl测试Google会提示无法解析。试了debian和centos都一样，迷惑了。
用netstat -tulpn命令查看的话，对于TCP连接，由于V2RAY同时监听了ipv4和ipv6，netstat会只显示ipv6部分。对于UDP连接，state列并不会显示LISTEN状态，但可以看到进程绑定的端口，同样由于V2RAY同时绑定了ipv4和ipv6，所以它也只显示了ipv6部分的绑定端口。

问题是解决了，但可能不适用你的情况，建议你提供SS-tproxy配置、v2ray配置、局域网拓扑的详细信息，才好解决问题。

但你提到在路由器中，将路由器的网关和DNS设置为代理服务器的IP，这有问题，因为路由器作为出口，网关应当是通过PPPoE拨号向ISP提供商获取的才对。我是把代理服务器连接在局域网的交换机上，交换机再和路由器连接，客户端从交换机接入的局域网，然后客户端的网关和DNS指向代理服务器就可以科学上网了，等于是客户端的流量从代理服务器那绕了一圈，也尝试过将代理服务器直接插在路由器上，这时客户端是无法联网的，可能是由于我的路由器几个LAN口并不是工作在交换状态。所以如果你配置好代理服务器以后，而且代理服务器本机测试dig google.com正常，那很有可能是局域网内连接的问题。

破案了，把v2ray服务器的域名换成IP或者把域名加到ignlist.ext可破。dns query死循环了，v2让chinadns用v2来解析v2的服务器域名IP，解析不出来

ifaws commented 4 years ago

似乎找到问题了，是V2Ray的Dokodemo-door有问题，检查端口监听，发现V2Ray只监听了TCP6的代理端口(12345,1080)，搜索了github上相同的V2ray Dokodemo-door问题，均未得到解决。
root@raspberrypi:/home/pi# netstat -an|grep LISTEN
tcp        0      0 0.0.0.0:60053           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN     
tcp6       0      0 :::60053                :::*                    LISTEN     
tcp6       0      0 :::53                   :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 :::1080                 :::*                    LISTEN     
tcp6       0      0 :::12345                :::*                    LISTEN     
tcp6       0      0 ::1:6010                :::*                    LISTEN     
unix  2      [ ACC ]     SEQPACKET  LISTENING     8472     /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     15645    /run/user/1000/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     15651    /run/user/1000/gnupg/S.gpg-agent.browser
unix  2      [ ACC ]     STREAM     LISTENING     11555    /run/avahi-daemon/socket
unix  2      [ ACC ]     STREAM     LISTENING     15654    /run/user/1000/gnupg/S.gpg-agent.extra
unix  2      [ ACC ]     STREAM     LISTENING     15656    /run/user/1000/gnupg/S.dirmngr
unix  2      [ ACC ]     STREAM     LISTENING     11560    /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     15658    /run/user/1000/gnupg/S.gpg-agent.ssh
unix  2      [ ACC ]     STREAM     LISTENING     15660    /run/user/1000/gnupg/S.gpg-agent
unix  2      [ ACC ]     STREAM     LISTENING     11564    /run/thd.socket
unix  2      [ ACC ]     STREAM     LISTENING     7807     /run/systemd/fsck.progress
unix  2      [ ACC ]     STREAM     LISTENING     12703    /var/run/dhcpcd.sock
unix  2      [ ACC ]     STREAM     LISTENING     12705    /var/run/dhcpcd.unpriv.sock
unix  2      [ ACC ]     STREAM     LISTENING     8430     /run/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     8436     /run/systemd/journal/stdout
老哥你这个问题解决了吗，我的症状跟你一样，但是只有在路由器里面设置网关和DNS为ss-tproxy的IP才会这样，如果本机测试，一点问题都没有，如果LAN内其它主机手动设置网关和DNS为ss-tproxy服务器，一开始还能用一会，后面就突然不行了，dnsmasq和chinadns-ng自己stop，restart能成功，但是日志里面的报错跟你一样，这种情况下，国内域名访问没问题，本机curl测试Google会提示无法解析。试了debian和centos都一样，迷惑了。
用netstat -tulpn命令查看的话，对于TCP连接，由于V2RAY同时监听了ipv4和ipv6，netstat会只显示ipv6部分。对于UDP连接，state列并不会显示LISTEN状态，但可以看到进程绑定的端口，同样由于V2RAY同时绑定了ipv4和ipv6，所以它也只显示了ipv6部分的绑定端口。问题是解决了，但可能不适用你的情况，建议你提供SS-tproxy配置、v2ray配置、局域网拓扑的详细信息，才好解决问题。但你提到在路由器中，将路由器的网关和DNS设置为代理服务器的IP，这有问题，因为路由器作为出口，网关应当是通过PPPoE拨号向ISP提供商获取的才对。我是把代理服务器连接在局域网的交换机上，交换机再和路由器连接，客户端从交换机接入的局域网，然后客户端的网关和DNS指向代理服务器就可以科学上网了，等于是客户端的流量从代理服务器那绕了一圈，也尝试过将代理服务器直接插在路由器上，这时客户端是无法联网的，可能是由于我的路由器几个LAN口并不是工作在交换状态。所以如果你配置好代理服务器以后，而且代理服务器本机测试dig google.com正常，那很有可能是局域网内连接的问题。
破案了，把v2ray服务器的域名换成IP或者把域名加到ignlist.ext可破。dns query死循环了，v2让chinadns用v2来解析v2的服务器域名IP，解析不出来

不应该存在这种情况吧，chinadns-ng本身没有问题啊，我的服务器地址就是用的域名，解析没有问题的。

tankren commented 4 years ago

似乎找到问题了，是V2Ray的Dokodemo-door有问题，检查端口监听，发现V2Ray只监听了TCP6的代理端口(12345,1080)，搜索了github上相同的V2ray Dokodemo-door问题，均未得到解决。
root@raspberrypi:/home/pi# netstat -an|grep LISTEN
tcp        0      0 0.0.0.0:60053           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN     
tcp6       0      0 :::60053                :::*                    LISTEN     
tcp6       0      0 :::53                   :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 :::1080                 :::*                    LISTEN     
tcp6       0      0 :::12345                :::*                    LISTEN     
tcp6       0      0 ::1:6010                :::*                    LISTEN     
unix  2      [ ACC ]     SEQPACKET  LISTENING     8472     /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     15645    /run/user/1000/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     15651    /run/user/1000/gnupg/S.gpg-agent.browser
unix  2      [ ACC ]     STREAM     LISTENING     11555    /run/avahi-daemon/socket
unix  2      [ ACC ]     STREAM     LISTENING     15654    /run/user/1000/gnupg/S.gpg-agent.extra
unix  2      [ ACC ]     STREAM     LISTENING     15656    /run/user/1000/gnupg/S.dirmngr
unix  2      [ ACC ]     STREAM     LISTENING     11560    /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     15658    /run/user/1000/gnupg/S.gpg-agent.ssh
unix  2      [ ACC ]     STREAM     LISTENING     15660    /run/user/1000/gnupg/S.gpg-agent
unix  2      [ ACC ]     STREAM     LISTENING     11564    /run/thd.socket
unix  2      [ ACC ]     STREAM     LISTENING     7807     /run/systemd/fsck.progress
unix  2      [ ACC ]     STREAM     LISTENING     12703    /var/run/dhcpcd.sock
unix  2      [ ACC ]     STREAM     LISTENING     12705    /var/run/dhcpcd.unpriv.sock
unix  2      [ ACC ]     STREAM     LISTENING     8430     /run/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     8436     /run/systemd/journal/stdout
老哥你这个问题解决了吗，我的症状跟你一样，但是只有在路由器里面设置网关和DNS为ss-tproxy的IP才会这样，如果本机测试，一点问题都没有，如果LAN内其它主机手动设置网关和DNS为ss-tproxy服务器，一开始还能用一会，后面就突然不行了，dnsmasq和chinadns-ng自己stop，restart能成功，但是日志里面的报错跟你一样，这种情况下，国内域名访问没问题，本机curl测试Google会提示无法解析。试了debian和centos都一样，迷惑了。
用netstat -tulpn命令查看的话，对于TCP连接，由于V2RAY同时监听了ipv4和ipv6，netstat会只显示ipv6部分。对于UDP连接，state列并不会显示LISTEN状态，但可以看到进程绑定的端口，同样由于V2RAY同时绑定了ipv4和ipv6，所以它也只显示了ipv6部分的绑定端口。问题是解决了，但可能不适用你的情况，建议你提供SS-tproxy配置、v2ray配置、局域网拓扑的详细信息，才好解决问题。但你提到在路由器中，将路由器的网关和DNS设置为代理服务器的IP，这有问题，因为路由器作为出口，网关应当是通过PPPoE拨号向ISP提供商获取的才对。我是把代理服务器连接在局域网的交换机上，交换机再和路由器连接，客户端从交换机接入的局域网，然后客户端的网关和DNS指向代理服务器就可以科学上网了，等于是客户端的流量从代理服务器那绕了一圈，也尝试过将代理服务器直接插在路由器上，这时客户端是无法联网的，可能是由于我的路由器几个LAN口并不是工作在交换状态。所以如果你配置好代理服务器以后，而且代理服务器本机测试dig google.com正常，那很有可能是局域网内连接的问题。
破案了，把v2ray服务器的域名换成IP或者把域名加到ignlist.ext可破。dns query死循环了，v2让chinadns用v2来解析v2的服务器域名IP，解析不出来
不应该存在这种情况吧，chinadns-ng本身没有问题啊，我的服务器地址就是用的域名，解析没有问题的。

我的情况就是这样，一开始可以，等一会就不行了，而且在透明代理服务器上curl谷歌直接说无法解析域名， v2的errorlog全部都是下面的信息

2020/02/20 22:20:01 [Warning] [651324813] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: failed to find an available destination > v2ray.com/core/common/retry: [dial tcp: lookup v2rayserver.com on 127.0.0.1:53: read udp 127.0.0.1:53418->127.0.0.1:53: i/o timeout dial tcp: lookup v2rayserver.com on 127.0.0.1:53: read udp 127.0.0.1:59109->127.0.0.1:53: i/o timeout dial tcp: lookup v2rayserver.com on 127.0.0.1:53: read udp 127.0.0.1:50319->127.0.0.1:53: i/o timeout dial tcp: lookup v2rayserver.com on 127.0.0.1:53: read udp 127.0.0.1:48415->127.0.0.1:53: i/o timeout dial tcp: lookup v2rayserver.com on 127.0.0.1:53: read udp 127.0.0.1:35591->127.0.0.1:53: i/o timeout] > v2ray.com/core/common/retry: all retry attempts failed

tankren commented 4 years ago

其实就是v2的服务器域名解析不了，v2不工作了，所有需要走可信dns解析的域名全部都解析不了。我的理解就是这样，我路由里面设置好了，只要明早还是正常的应该就是这个原因了。晚安！

tankren commented 4 years ago

似乎找到问题了，是V2Ray的Dokodemo-door有问题，检查端口监听，发现V2Ray只监听了TCP6的代理端口(12345,1080)，搜索了github上相同的V2ray Dokodemo-door问题，均未得到解决。
root@raspberrypi:/home/pi# netstat -an|grep LISTEN
tcp        0      0 0.0.0.0:60053           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN     
tcp6       0      0 :::60053                :::*                    LISTEN     
tcp6       0      0 :::53                   :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 :::1080                 :::*                    LISTEN     
tcp6       0      0 :::12345                :::*                    LISTEN     
tcp6       0      0 ::1:6010                :::*                    LISTEN     
unix  2      [ ACC ]     SEQPACKET  LISTENING     8472     /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     15645    /run/user/1000/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     15651    /run/user/1000/gnupg/S.gpg-agent.browser
unix  2      [ ACC ]     STREAM     LISTENING     11555    /run/avahi-daemon/socket
unix  2      [ ACC ]     STREAM     LISTENING     15654    /run/user/1000/gnupg/S.gpg-agent.extra
unix  2      [ ACC ]     STREAM     LISTENING     15656    /run/user/1000/gnupg/S.dirmngr
unix  2      [ ACC ]     STREAM     LISTENING     11560    /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     15658    /run/user/1000/gnupg/S.gpg-agent.ssh
unix  2      [ ACC ]     STREAM     LISTENING     15660    /run/user/1000/gnupg/S.gpg-agent
unix  2      [ ACC ]     STREAM     LISTENING     11564    /run/thd.socket
unix  2      [ ACC ]     STREAM     LISTENING     7807     /run/systemd/fsck.progress
unix  2      [ ACC ]     STREAM     LISTENING     12703    /var/run/dhcpcd.sock
unix  2      [ ACC ]     STREAM     LISTENING     12705    /var/run/dhcpcd.unpriv.sock
unix  2      [ ACC ]     STREAM     LISTENING     8430     /run/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     8436     /run/systemd/journal/stdout
老哥你这个问题解决了吗，我的症状跟你一样，但是只有在路由器里面设置网关和DNS为ss-tproxy的IP才会这样，如果本机测试，一点问题都没有，如果LAN内其它主机手动设置网关和DNS为ss-tproxy服务器，一开始还能用一会，后面就突然不行了，dnsmasq和chinadns-ng自己stop，restart能成功，但是日志里面的报错跟你一样，这种情况下，国内域名访问没问题，本机curl测试Google会提示无法解析。试了debian和centos都一样，迷惑了。
用netstat -tulpn命令查看的话，对于TCP连接，由于V2RAY同时监听了ipv4和ipv6，netstat会只显示ipv6部分。对于UDP连接，state列并不会显示LISTEN状态，但可以看到进程绑定的端口，同样由于V2RAY同时绑定了ipv4和ipv6，所以它也只显示了ipv6部分的绑定端口。问题是解决了，但可能不适用你的情况，建议你提供SS-tproxy配置、v2ray配置、局域网拓扑的详细信息，才好解决问题。但你提到在路由器中，将路由器的网关和DNS设置为代理服务器的IP，这有问题，因为路由器作为出口，网关应当是通过PPPoE拨号向ISP提供商获取的才对。我是把代理服务器连接在局域网的交换机上，交换机再和路由器连接，客户端从交换机接入的局域网，然后客户端的网关和DNS指向代理服务器就可以科学上网了，等于是客户端的流量从代理服务器那绕了一圈，也尝试过将代理服务器直接插在路由器上，这时客户端是无法联网的，可能是由于我的路由器几个LAN口并不是工作在交换状态。所以如果你配置好代理服务器以后，而且代理服务器本机测试dig google.com正常，那很有可能是局域网内连接的问题。
破案了，把v2ray服务器的域名换成IP或者把域名加到ignlist.ext可破。dns query死循环了，v2让chinadns用v2来解析v2的服务器域名IP，解析不出来
不应该存在这种情况吧，chinadns-ng本身没有问题啊，我的服务器地址就是用的域名，解析没有问题的。

我了个去，早上起来国内国外全部断网。透明代理主机连114都ping不通，扒拉了点资料应该是没有外网了，路由器端设置网关之后，透明代理主机的网关指向了自己，我这个代理主机是虚拟机，系统是centos，用一条命令把网关改回路由器就恢复了。 route add default gw 10.0.0.1 dev ens160

ifaws commented 4 years ago

似乎找到问题了，是V2Ray的Dokodemo-door有问题，检查端口监听，发现V2Ray只监听了TCP6的代理端口(12345,1080)，搜索了github上相同的V2ray Dokodemo-door问题，均未得到解决。
root@raspberrypi:/home/pi# netstat -an|grep LISTEN
tcp        0      0 0.0.0.0:60053           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN     
tcp6       0      0 :::60053                :::*                    LISTEN     
tcp6       0      0 :::53                   :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 :::1080                 :::*                    LISTEN     
tcp6       0      0 :::12345                :::*                    LISTEN     
tcp6       0      0 ::1:6010                :::*                    LISTEN     
unix  2      [ ACC ]     SEQPACKET  LISTENING     8472     /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     15645    /run/user/1000/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     15651    /run/user/1000/gnupg/S.gpg-agent.browser
unix  2      [ ACC ]     STREAM     LISTENING     11555    /run/avahi-daemon/socket
unix  2      [ ACC ]     STREAM     LISTENING     15654    /run/user/1000/gnupg/S.gpg-agent.extra
unix  2      [ ACC ]     STREAM     LISTENING     15656    /run/user/1000/gnupg/S.dirmngr
unix  2      [ ACC ]     STREAM     LISTENING     11560    /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     15658    /run/user/1000/gnupg/S.gpg-agent.ssh
unix  2      [ ACC ]     STREAM     LISTENING     15660    /run/user/1000/gnupg/S.gpg-agent
unix  2      [ ACC ]     STREAM     LISTENING     11564    /run/thd.socket
unix  2      [ ACC ]     STREAM     LISTENING     7807     /run/systemd/fsck.progress
unix  2      [ ACC ]     STREAM     LISTENING     12703    /var/run/dhcpcd.sock
unix  2      [ ACC ]     STREAM     LISTENING     12705    /var/run/dhcpcd.unpriv.sock
unix  2      [ ACC ]     STREAM     LISTENING     8430     /run/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     8436     /run/systemd/journal/stdout
老哥你这个问题解决了吗，我的症状跟你一样，但是只有在路由器里面设置网关和DNS为ss-tproxy的IP才会这样，如果本机测试，一点问题都没有，如果LAN内其它主机手动设置网关和DNS为ss-tproxy服务器，一开始还能用一会，后面就突然不行了，dnsmasq和chinadns-ng自己stop，restart能成功，但是日志里面的报错跟你一样，这种情况下，国内域名访问没问题，本机curl测试Google会提示无法解析。试了debian和centos都一样，迷惑了。
用netstat -tulpn命令查看的话，对于TCP连接，由于V2RAY同时监听了ipv4和ipv6，netstat会只显示ipv6部分。对于UDP连接，state列并不会显示LISTEN状态，但可以看到进程绑定的端口，同样由于V2RAY同时绑定了ipv4和ipv6，所以它也只显示了ipv6部分的绑定端口。问题是解决了，但可能不适用你的情况，建议你提供SS-tproxy配置、v2ray配置、局域网拓扑的详细信息，才好解决问题。但你提到在路由器中，将路由器的网关和DNS设置为代理服务器的IP，这有问题，因为路由器作为出口，网关应当是通过PPPoE拨号向ISP提供商获取的才对。我是把代理服务器连接在局域网的交换机上，交换机再和路由器连接，客户端从交换机接入的局域网，然后客户端的网关和DNS指向代理服务器就可以科学上网了，等于是客户端的流量从代理服务器那绕了一圈，也尝试过将代理服务器直接插在路由器上，这时客户端是无法联网的，可能是由于我的路由器几个LAN口并不是工作在交换状态。所以如果你配置好代理服务器以后，而且代理服务器本机测试dig google.com正常，那很有可能是局域网内连接的问题。
破案了，把v2ray服务器的域名换成IP或者把域名加到ignlist.ext可破。dns query死循环了，v2让chinadns用v2来解析v2的服务器域名IP，解析不出来
不应该存在这种情况吧，chinadns-ng本身没有问题啊，我的服务器地址就是用的域名，解析没有问题的。
我了个去，早上起来国内国外全部断网。透明代理主机连114都ping不通，扒拉了点资料应该是没有外网了，路由器端设置网关之后，透明代理主机的网关指向了自己，我这个代理主机是虚拟机，系统是centos，用一条命令把网关改回路由器就恢复了。 route add default gw 10.0.0.1 dev ens160

路由器设置网关，你是配置了路由器DHCP，让网关和DNS指向了虚拟代理主机吗？然后全局科学上网

tankren commented 4 years ago

似乎找到问题了，是V2Ray的Dokodemo-door有问题，检查端口监听，发现V2Ray只监听了TCP6的代理端口(12345,1080)，搜索了github上相同的V2ray Dokodemo-door问题，均未得到解决。
root@raspberrypi:/home/pi# netstat -an|grep LISTEN
tcp        0      0 0.0.0.0:60053           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN     
tcp6       0      0 :::60053                :::*                    LISTEN     
tcp6       0      0 :::53                   :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 :::1080                 :::*                    LISTEN     
tcp6       0      0 :::12345                :::*                    LISTEN     
tcp6       0      0 ::1:6010                :::*                    LISTEN     
unix  2      [ ACC ]     SEQPACKET  LISTENING     8472     /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     15645    /run/user/1000/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     15651    /run/user/1000/gnupg/S.gpg-agent.browser
unix  2      [ ACC ]     STREAM     LISTENING     11555    /run/avahi-daemon/socket
unix  2      [ ACC ]     STREAM     LISTENING     15654    /run/user/1000/gnupg/S.gpg-agent.extra
unix  2      [ ACC ]     STREAM     LISTENING     15656    /run/user/1000/gnupg/S.dirmngr
unix  2      [ ACC ]     STREAM     LISTENING     11560    /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     15658    /run/user/1000/gnupg/S.gpg-agent.ssh
unix  2      [ ACC ]     STREAM     LISTENING     15660    /run/user/1000/gnupg/S.gpg-agent
unix  2      [ ACC ]     STREAM     LISTENING     11564    /run/thd.socket
unix  2      [ ACC ]     STREAM     LISTENING     7807     /run/systemd/fsck.progress
unix  2      [ ACC ]     STREAM     LISTENING     12703    /var/run/dhcpcd.sock
unix  2      [ ACC ]     STREAM     LISTENING     12705    /var/run/dhcpcd.unpriv.sock
unix  2      [ ACC ]     STREAM     LISTENING     8430     /run/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     8436     /run/systemd/journal/stdout
老哥你这个问题解决了吗，我的症状跟你一样，但是只有在路由器里面设置网关和DNS为ss-tproxy的IP才会这样，如果本机测试，一点问题都没有，如果LAN内其它主机手动设置网关和DNS为ss-tproxy服务器，一开始还能用一会，后面就突然不行了，dnsmasq和chinadns-ng自己stop，restart能成功，但是日志里面的报错跟你一样，这种情况下，国内域名访问没问题，本机curl测试Google会提示无法解析。试了debian和centos都一样，迷惑了。
用netstat -tulpn命令查看的话，对于TCP连接，由于V2RAY同时监听了ipv4和ipv6，netstat会只显示ipv6部分。对于UDP连接，state列并不会显示LISTEN状态，但可以看到进程绑定的端口，同样由于V2RAY同时绑定了ipv4和ipv6，所以它也只显示了ipv6部分的绑定端口。问题是解决了，但可能不适用你的情况，建议你提供SS-tproxy配置、v2ray配置、局域网拓扑的详细信息，才好解决问题。但你提到在路由器中，将路由器的网关和DNS设置为代理服务器的IP，这有问题，因为路由器作为出口，网关应当是通过PPPoE拨号向ISP提供商获取的才对。我是把代理服务器连接在局域网的交换机上，交换机再和路由器连接，客户端从交换机接入的局域网，然后客户端的网关和DNS指向代理服务器就可以科学上网了，等于是客户端的流量从代理服务器那绕了一圈，也尝试过将代理服务器直接插在路由器上，这时客户端是无法联网的，可能是由于我的路由器几个LAN口并不是工作在交换状态。所以如果你配置好代理服务器以后，而且代理服务器本机测试dig google.com正常，那很有可能是局域网内连接的问题。
破案了，把v2ray服务器的域名换成IP或者把域名加到ignlist.ext可破。dns query死循环了，v2让chinadns用v2来解析v2的服务器域名IP，解析不出来
不应该存在这种情况吧，chinadns-ng本身没有问题啊，我的服务器地址就是用的域名，解析没有问题的。
我了个去，早上起来国内国外全部断网。透明代理主机连114都ping不通，扒拉了点资料应该是没有外网了，路由器端设置网关之后，透明代理主机的网关指向了自己，我这个代理主机是虚拟机，系统是centos，用一条命令把网关改回路由器就恢复了。 route add default gw 10.0.0.1 dev ens160
路由器设置网关，你是配置了路由器DHCP，让网关和DNS指向了虚拟代理主机吗？然后全局科学上网

是的，pfsense做主路由， DHCP Server里面把网关和DNS指向透明代理虚拟机，透明代理虚拟机的网关要手动指向pfsense，不然没有外网，这个好像跟流行的ikuai+lede的网关配置是一致的。这么配置这样就能全局科学上网了

ifaws commented 4 years ago

似乎找到问题了，是V2Ray的Dokodemo-door有问题，检查端口监听，发现V2Ray只监听了TCP6的代理端口(12345,1080)，搜索了github上相同的V2ray Dokodemo-door问题，均未得到解决。
root@raspberrypi:/home/pi# netstat -an|grep LISTEN
tcp        0      0 0.0.0.0:60053           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN     
tcp6       0      0 :::60053                :::*                    LISTEN     
tcp6       0      0 :::53                   :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 :::1080                 :::*                    LISTEN     
tcp6       0      0 :::12345                :::*                    LISTEN     
tcp6       0      0 ::1:6010                :::*                    LISTEN     
unix  2      [ ACC ]     SEQPACKET  LISTENING     8472     /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     15645    /run/user/1000/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     15651    /run/user/1000/gnupg/S.gpg-agent.browser
unix  2      [ ACC ]     STREAM     LISTENING     11555    /run/avahi-daemon/socket
unix  2      [ ACC ]     STREAM     LISTENING     15654    /run/user/1000/gnupg/S.gpg-agent.extra
unix  2      [ ACC ]     STREAM     LISTENING     15656    /run/user/1000/gnupg/S.dirmngr
unix  2      [ ACC ]     STREAM     LISTENING     11560    /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     15658    /run/user/1000/gnupg/S.gpg-agent.ssh
unix  2      [ ACC ]     STREAM     LISTENING     15660    /run/user/1000/gnupg/S.gpg-agent
unix  2      [ ACC ]     STREAM     LISTENING     11564    /run/thd.socket
unix  2      [ ACC ]     STREAM     LISTENING     7807     /run/systemd/fsck.progress
unix  2      [ ACC ]     STREAM     LISTENING     12703    /var/run/dhcpcd.sock
unix  2      [ ACC ]     STREAM     LISTENING     12705    /var/run/dhcpcd.unpriv.sock
unix  2      [ ACC ]     STREAM     LISTENING     8430     /run/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     8436     /run/systemd/journal/stdout
老哥你这个问题解决了吗，我的症状跟你一样，但是只有在路由器里面设置网关和DNS为ss-tproxy的IP才会这样，如果本机测试，一点问题都没有，如果LAN内其它主机手动设置网关和DNS为ss-tproxy服务器，一开始还能用一会，后面就突然不行了，dnsmasq和chinadns-ng自己stop，restart能成功，但是日志里面的报错跟你一样，这种情况下，国内域名访问没问题，本机curl测试Google会提示无法解析。试了debian和centos都一样，迷惑了。
用netstat -tulpn命令查看的话，对于TCP连接，由于V2RAY同时监听了ipv4和ipv6，netstat会只显示ipv6部分。对于UDP连接，state列并不会显示LISTEN状态，但可以看到进程绑定的端口，同样由于V2RAY同时绑定了ipv4和ipv6，所以它也只显示了ipv6部分的绑定端口。问题是解决了，但可能不适用你的情况，建议你提供SS-tproxy配置、v2ray配置、局域网拓扑的详细信息，才好解决问题。但你提到在路由器中，将路由器的网关和DNS设置为代理服务器的IP，这有问题，因为路由器作为出口，网关应当是通过PPPoE拨号向ISP提供商获取的才对。我是把代理服务器连接在局域网的交换机上，交换机再和路由器连接，客户端从交换机接入的局域网，然后客户端的网关和DNS指向代理服务器就可以科学上网了，等于是客户端的流量从代理服务器那绕了一圈，也尝试过将代理服务器直接插在路由器上，这时客户端是无法联网的，可能是由于我的路由器几个LAN口并不是工作在交换状态。所以如果你配置好代理服务器以后，而且代理服务器本机测试dig google.com正常，那很有可能是局域网内连接的问题。
破案了，把v2ray服务器的域名换成IP或者把域名加到ignlist.ext可破。dns query死循环了，v2让chinadns用v2来解析v2的服务器域名IP，解析不出来
不应该存在这种情况吧，chinadns-ng本身没有问题啊，我的服务器地址就是用的域名，解析没有问题的。
我了个去，早上起来国内国外全部断网。透明代理主机连114都ping不通，扒拉了点资料应该是没有外网了，路由器端设置网关之后，透明代理主机的网关指向了自己，我这个代理主机是虚拟机，系统是centos，用一条命令把网关改回路由器就恢复了。 route add default gw 10.0.0.1 dev ens160
路由器设置网关，你是配置了路由器DHCP，让网关和DNS指向了虚拟代理主机吗？然后全局科学上网
是的，pfsense做主路由， DHCP Server里面把网关和DNS指向透明代理虚拟机，透明代理虚拟机的网关要手动指向pfsense，不然没有外网，这个好像跟流行的ikuai+lede的网关配置是一致的。这么配置这样就能全局科学上网了

这样的话，走代理的外网流量没什么瓶颈，但走直连的国内流量带宽受限，现在家用带宽都下行500/800了，全局翻墙的话还是弄个软路由，部署在路由器和内网交换机中间比较好。

tankren commented 4 years ago

似乎找到问题了，是V2Ray的Dokodemo-door有问题，检查端口监听，发现V2Ray只监听了TCP6的代理端口(12345,1080)，搜索了github上相同的V2ray Dokodemo-door问题，均未得到解决。
root@raspberrypi:/home/pi# netstat -an|grep LISTEN
tcp        0      0 0.0.0.0:60053           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN     
tcp6       0      0 :::60053                :::*                    LISTEN     
tcp6       0      0 :::53                   :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 :::1080                 :::*                    LISTEN     
tcp6       0      0 :::12345                :::*                    LISTEN     
tcp6       0      0 ::1:6010                :::*                    LISTEN     
unix  2      [ ACC ]     SEQPACKET  LISTENING     8472     /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     15645    /run/user/1000/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     15651    /run/user/1000/gnupg/S.gpg-agent.browser
unix  2      [ ACC ]     STREAM     LISTENING     11555    /run/avahi-daemon/socket
unix  2      [ ACC ]     STREAM     LISTENING     15654    /run/user/1000/gnupg/S.gpg-agent.extra
unix  2      [ ACC ]     STREAM     LISTENING     15656    /run/user/1000/gnupg/S.dirmngr
unix  2      [ ACC ]     STREAM     LISTENING     11560    /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     15658    /run/user/1000/gnupg/S.gpg-agent.ssh
unix  2      [ ACC ]     STREAM     LISTENING     15660    /run/user/1000/gnupg/S.gpg-agent
unix  2      [ ACC ]     STREAM     LISTENING     11564    /run/thd.socket
unix  2      [ ACC ]     STREAM     LISTENING     7807     /run/systemd/fsck.progress
unix  2      [ ACC ]     STREAM     LISTENING     12703    /var/run/dhcpcd.sock
unix  2      [ ACC ]     STREAM     LISTENING     12705    /var/run/dhcpcd.unpriv.sock
unix  2      [ ACC ]     STREAM     LISTENING     8430     /run/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     8436     /run/systemd/journal/stdout
老哥你这个问题解决了吗，我的症状跟你一样，但是只有在路由器里面设置网关和DNS为ss-tproxy的IP才会这样，如果本机测试，一点问题都没有，如果LAN内其它主机手动设置网关和DNS为ss-tproxy服务器，一开始还能用一会，后面就突然不行了，dnsmasq和chinadns-ng自己stop，restart能成功，但是日志里面的报错跟你一样，这种情况下，国内域名访问没问题，本机curl测试Google会提示无法解析。试了debian和centos都一样，迷惑了。
用netstat -tulpn命令查看的话，对于TCP连接，由于V2RAY同时监听了ipv4和ipv6，netstat会只显示ipv6部分。对于UDP连接，state列并不会显示LISTEN状态，但可以看到进程绑定的端口，同样由于V2RAY同时绑定了ipv4和ipv6，所以它也只显示了ipv6部分的绑定端口。问题是解决了，但可能不适用你的情况，建议你提供SS-tproxy配置、v2ray配置、局域网拓扑的详细信息，才好解决问题。但你提到在路由器中，将路由器的网关和DNS设置为代理服务器的IP，这有问题，因为路由器作为出口，网关应当是通过PPPoE拨号向ISP提供商获取的才对。我是把代理服务器连接在局域网的交换机上，交换机再和路由器连接，客户端从交换机接入的局域网，然后客户端的网关和DNS指向代理服务器就可以科学上网了，等于是客户端的流量从代理服务器那绕了一圈，也尝试过将代理服务器直接插在路由器上，这时客户端是无法联网的，可能是由于我的路由器几个LAN口并不是工作在交换状态。所以如果你配置好代理服务器以后，而且代理服务器本机测试dig google.com正常，那很有可能是局域网内连接的问题。
破案了，把v2ray服务器的域名换成IP或者把域名加到ignlist.ext可破。dns query死循环了，v2让chinadns用v2来解析v2的服务器域名IP，解析不出来
不应该存在这种情况吧，chinadns-ng本身没有问题啊，我的服务器地址就是用的域名，解析没有问题的。
我了个去，早上起来国内国外全部断网。透明代理主机连114都ping不通，扒拉了点资料应该是没有外网了，路由器端设置网关之后，透明代理主机的网关指向了自己，我这个代理主机是虚拟机，系统是centos，用一条命令把网关改回路由器就恢复了。 route add default gw 10.0.0.1 dev ens160
路由器设置网关，你是配置了路由器DHCP，让网关和DNS指向了虚拟代理主机吗？然后全局科学上网
是的，pfsense做主路由， DHCP Server里面把网关和DNS指向透明代理虚拟机，透明代理虚拟机的网关要手动指向pfsense，不然没有外网，这个好像跟流行的ikuai+lede的网关配置是一致的。这么配置这样就能全局科学上网了
这样的话，走代理的外网流量没什么瓶颈，但走直连的国内流量带宽受限，现在家用带宽都下行500/800了，全局翻墙的话还是弄个软路由，部署在路由器和内网交换机中间比较好。

pfsense就是x86软路由来着，J1900的，作为防火墙+反代