search

zfl9 / ss-tproxy

ss/v2ray/xray/trojan/hysteria/naive/socks5 透明代理
GNU Affero General Public License v3.0
2.26k stars 433 forks source link

访问京东经常出现无法加载的情况（应该是直连DNS污染问题，换个DNS即可） #243

Closed derekhe closed 1 year ago

derekhe commented 1 year ago

最新的4.7.6版本，看了下应该是DNS解析出现一些问题。其他网站都没事。

zfl9 commented 1 year ago

ss-tproxy.conf 配置 ？

dns 相关解析 log ？

手机还是电脑(网页)，如果是网页，检查下F12控制台，看看什么情况。

derekhe commented 1 year ago

网页版本

## mode
#mode='global'  # 全局：{ignlist}走直连，其他走代理
#mode='gfwlist' # 黑名单：{gfwlist}走代理，其他走直连 (回国模式也是这个，后面有详细说明)
mode='chnroute' # 大陆白名单：{gfwlist}走代理，{ignlist,chnlist,chnroute}走直连，其他走代理

## ipv4/6
ipv4='true'     # 是否对ipv4启用'透明代理': true启用 false不启用
ipv6='false'    # 是否对ipv6启用'透明代理': true启用 false不启用

## tproxy
tproxy='true'  # true:  TPROXY(tcp)   + TPROXY(udp) ## 纯 tproxy 模式 ##
                # false: REDIRECT(tcp) + TPROXY(udp) ## redirect 模式  ##
                #
                # 具体取决于'本机代理进程'的透明代理传入'协议'
                #
                # ss/ssr/trojan 通常为 redirect 模式
                # v2ray 两者都支持，具体取决于 v2ray 配置
                # ipt2socks 默认为纯 tproxy 模式，也可切换为 redirect 模式
                # ss-libev 3.3.5+ 支持纯 tproxy 模式，参数为"-T"、"tcp_tproxy": true
                # trojan 原生不支持 udp 透明代理，但可以配合 ipt2socks 来实现
                # trojan-go 只使用纯 tproxy 模式，支持 tcp 和 udp
                #
                # 其他代理软件请自行甄别测试，配置错误将无法正常透明代理

## tcponly
tcponly='false' # true:仅代理TCP流量 | false:代理TCP和UDP流量
                # 取决与'代理套件'，有些代理/机场不支持UDP协议的代理
                # DNS查询默认走UDP，若代理不支持UDP，请将此选项设为true

## selfonly
selfonly='false' # true: 只代理ss-tproxy主机(本机)传出的流量
                 # false: 代理本机、内网机传出的流量(网关和dns指向ss-tproxy主机)
                 # 由于dns_remote必须走代理，且dns逻辑在本机进行，因此本机必须走代理
                 # 虽然可以只处理dns流量，其他流量不走代理，但感觉意义不大，还是简单点好

## proxy
#
# 本机代理进程相关，如透明代理端口，进程启动和停止命令(如果想自己控制进程启停，可以留空)
#
# ss-tproxy要求"代理进程"不参与ip分流，也不参与dns解析，专心让iptables过来的tcp/udp流量走代理即可
# 本机代理进程只会收到"纯ip"的tcp/udp流量，不会有dns相关的东西让你知晓，因为这些已被dns解析组件处理
# 因此ss-tproxy的设计原则是：各组件只负责自己的专业领域，无需知晓透明代理的全局面貌，做好自己的事就行
#
# 如果要切换代理/节点，请直接操作代理进程，而不是修改ss-tproxy.conf、重启ss-tproxy
# 因为这是一个重量级操作，除非tproxy模式、tcponly模式等涉及iptables规则的配置发生了更改
# 换句话说，ss-tproxy应该主要用于iptables管理，以及附带的dns方案，顺便帮你启动/关闭代理进程
#
proxy_procgroup='proxy'  # 本机代理进程的group(fsgid)，所有代理进程都需要以此身份运行，用于流量放行
                         # 不允许填root或0，脚本会自动帮你创建group(如果填的是name)，建议使用name
                         #
proxy_tcpport='60080'    # ss/ssr/v2ray/ipt2socks 等本机进程的 TCP 监听端口，该端口支持"透明代理"
proxy_udpport='60080'    # ss/ssr/v2ray/ipt2socks 等本机进程的 UDP 监听端口，该端口支持"透明代理"
                         # 代理进程只需监听"127.0.0.1"(v4环境)+"::1"(v6环境)，不需要监听"全0地址"
                         #
proxy_startcmd='start_hy'        # 用于启动"本机代理进程(组)"的 shell 命令行，该命令行不应该执行过长时间
proxy_stopcmd='stop_hy'         # 用于关闭"本机代理进程(组)"的 shell 命令行，该命令行不应该执行过长时间
                         # 如果想自己接管"本机代理进程"的启动/停止，可以在startcmd/stopcmd上留空
                         #
                         # 如果命令行比较长，建议封装为函数，然后在startcmd/stopcmd中调用这些函数
                         # shell函数可以定义在ss-tproxy.conf的任何位置，比如ss-tproxy.conf的末尾
                         #
                         # 可以调用 set_proxy_group 给可执行文件设置所属 group、setgid 权限位
                         # 比如："set_proxy_group ss-redir"，执行 ss-redir 时会自动切换 group

## dns
dns_custom='false'                    # true:使用自定义dns方案(高级用户,见下面的说明) | false:使用内置dns方案
                                      # 使用自定义dns方案时，所有dns相关的配置被忽略，内置的域名分流规则也会失效
                                      # 需要自己实现域名解析/分流；udp代理未启用时，如果想走代理，请记得走tcp协议
                                      #
dns_procgroup='proxy_dns'             # dns进程的group(fsgid)，不能与proxy_procgroup相同，所有dns进程都需要以此身份运行
                                      # 不允许填root或0，脚本会自动帮你创建group(如果填的是name)，建议使用name而不是gid
                                      #
dns_mainport='5353'                     # dns请求的逻辑入口(udp监听端口)，脚本内部会将"所有"dns请求重定向至此udp端口
                                      # 监听地址必须能覆盖到"127.0.0.1"(v4环境)+"::1"(v6环境)，用于接收本机dns请求
                                      # 如果要代理内网，则监听地址还需覆盖到相关网卡，为了简单，建议监听通配地址(全0)
                                      #
                                      # 下面的这些 dns_* 配置，只在使用"内置dns方案"时有效
                                      #
                                      # 直连DNS和远程DNS，控制的是"内置dns组件"的上游dns服务器参数
                                      # white和black，控制的是"ipset白名单/黑名单"，即：直连还是代理
                                      # 放在这里是为了方便修改dns配置，不必修改ignlist.ext/gfwlist.ext
                                      #
                                      # white和black允许以下3类值，以dns_direct_white为例(其他同理)
                                      # - 'true'    # dns_direct的ip加入白名单，使其走直连
                                      # - 'false'   # dns_direct的ip不加入白名单，比如局域网ip
                                      # - '1.2.3.4' # 将1.2.3.4这个ip加入白名单，可填多个ip，空格隔开
                                      # > 注意，对于填写ip的情况，带6的选项请填ipv6地址，不带6的填ipv4地址
                                      #
dns_direct='223.5.5.5#53'             # 直连DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
dns_direct6='240C::6666#53'           # 直连DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
dns_direct_white='true'               # 将dns_direct的ip加入白名单(global/chnroute)，使其走直连
dns_direct6_white='true'              # 将dns_direct6的ip加入白名单(global/chnroute)，使其走直连
                                      #
dns_remote='8.8.8.8#53'               # 远程DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
dns_remote6='2001:4860:4860::8888#53' # 远程DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
dns_remote_black='true'               # 将dns_remote的ip加入黑名单(gfwlist/chnroute)，使其走代理
dns_remote6_black='true'              # 将dns_remote6的ip加入黑名单(gfwlist/chnroute)，使其走代理

## dnsmasq
# 使用自定义dns方案时，dnsmasq相关配置被忽略，dnsmasq不会启动
# 这里允许dnsmasq监听其他端口，是为了在它前面加入其他进程，优先处理dns
dnsmasq_bind_port=''                    # dnsmasq监听端口，留空表示端口同dns_mainport
dnsmasq_cache_size='4096'               # 最多缓存多少条，0表示禁用缓存，太大会影响性能
dnsmasq_cache_time_min='360'           # 最短缓存多少秒，上限值为3600，0表示禁用此功能
dnsmasq_query_maxcnt='2048'             # dns查询最大并发数(dns-forward-max)，默认150
dnsmasq_log_enable='false'              # 记录详细日志，除非进行调试，否则不建议启用
dnsmasq_log_file='/var/log/dnsmasq.log' # 日志文件，如果不想保存日志可以改为 /dev/null
dnsmasq_conf_dir=()                     # `--conf-dir` 选项的参数，可以填多个，空格隔开
dnsmasq_conf_file=()                    # `--conf-file` 选项的参数，可以填多个，空格隔开
dnsmasq_conf_string=()                  # 自定义配置，一个数组元素就是一行配置，空格隔开

## chinadns
# 使用自定义dns方案时，chinadns相关配置被忽略，chinadns-ng不会启动
chinadns_for_gfwlist='true'              # 用于mode=gfwlist，提升域名匹配性能
chinadns_bind_port='65353'               # 监听端口，若 65353 被占用，请注意更改
chinadns_chnlist_first='false'           # 优先加载 chnlist 域名 (默认优先 gfwlist)
chinadns_extra_options=''                # 其他附加的命令行选项(已有的选项就别再填了)
chinadns_verbose='true'                 # 记录详细日志，除非进行调试，否则不建议启用
chinadns_logfile='/var/log/chinadns.log' # 日志文件，如果不想保存日志可以改为 /dev/null

## dns2tcp
# 使用自定义dns方案时，dns2tcp相关配置被忽略，dns2tcp不会启动
# 如果udp代理效果一般，建议启用dns2tcp，个人测试tcp查询快于udp，可能是isp/gfw对udp进行了qos
# 这里提供禁用选项，主要是为了方便使用其他dns工具替代dns2tcp，比如dnsproxy，走doh，也是tcp协议
dns2tcp_enable='auto'                   # auto:tcponly时启用 | true:总是启用 | false:禁用
dns2tcp_bind_port='65454'               # 监听端口，若 65454 被占用，请注意更改
dns2tcp_extra_options=''                # 其他附加的命令行选项(已有的选项就别再填了)
dns2tcp_verbose='true'                 # 记录详细日志，除非进行调试，否则不建议启用
dns2tcp_logfile='/var/log/dns2tcp.log'  # 日志文件，如果不想保存日志可以改为 /dev/null

## ipts
ipts_if_lo='lo'                     # 环回接口的名称，在标准发行版中，通常为 lo，如果不是请修改
ipts_rt_tab='233'                   # iproute2 路由表名或表 ID，除非产生冲突，否则不建议改动该选项
ipts_rt_mark='0x2333'               # iproute2 策略路由的防火墙标记，除非产生冲突，否则不建议改动该选项
ipts_set_snat='false'               # 设置 ipv4 MASQUERADE(SNAT) 规则，selfonly=false 时有效，详见 README
ipts_set_snat6='false'              # 设置 ipv6 MASQUERADE(SNAT) 规则，selfonly=false 时有效，详见 README
ipts_reddns_onstop='223.5.5.5#53'   # stop后重定向内网主机发来的dns至指定dns，selfonly=false 时有效，详见 README
ipts_reddns6_onstop='240C::6666#53' # stop后重定向内网主机发来的dns至指定dns，selfonly=false 时有效，详见 README
ipts_proxy_dst_port=''              # 要代理哪些端口，留空表示全部，多个逗号隔开，冒号表示范围(含边界)，详见 README
ipts_drop_quic='always'            # 丢弃发往"黑名单"的QUIC: 留空:不丢弃 | tcponly:tcponly时丢弃 | always:总是丢弃

## opts
opts_ss_netstat='auto'      # auto/ss/netstat，用哪个端口检测工具: auto(自动选择,优先考虑ss) | ss | netstat

## url
# 用于更新gfwlist.txt，格式：`域名后缀`或`server=/域名后缀/dns_ip`(dnsmasq格式，只关心`域名后缀`字段)
url_gfwlist='https://raw.githubusercontent.com/pexcn/daily/gh-pages/gfwlist/gfwlist.txt'
# 用于更新chnlist.txt，格式：`域名后缀`或`server=/域名后缀/dns_ip`(dnsmasq格式，只关心`域名后缀`字段)
url_chnlist='https://raw.githubusercontent.com/felixonmars/dnsmasq-china-list/master/accelerated-domains.china.conf'
# 用于更新chnroute*.txt，目前只支持APNIC格式，如果想使用其他ip库，建议在当前文件重写ss-tproxy的相关函数
url_chnroute='https://ftp.apnic.net/stats/apnic/delegated-apnic-latest'

## 回国模式
#
# 在国外访问大陆网站时，可能会出现ip区域限制等问题，导致无法正常使用大陆网络服务
# 此时可以使用"回国模式"，通过代理回到国内，摆脱ip区域限制等问题，原理与翻墙类似
#
# ss-tproxy支持回国模式，要切换到回国模式，请执行以下步骤：
#
# - 使用 gfwlist 分流模式，即 mode='gfwlist'
# - 互换 dns_direct* 和 dns_remote* 的配置内容
# - url_gfwlist 改为大陆域名列表的url，如 url_chnlist
# - 注释 gfwlist.ext 中的 Telegram 地址段 (这是给国内用的)
# - 执行 ss-tproxy update-gfwlist (将gfwlist.txt换成大陆域名)
#
# 以上步骤只需执行一次，之后就是正常使用 ss-tproxy start/stop 了

###################### 钩子函数 ######################

# 此函数在"启动逻辑之前"执行
pre_start() {
    # do something
    return
}

# 此函数在"启动逻辑之后"执行
post_start() {
    # do something
    return
}

# 此函数在"停止逻辑之前"执行
pre_stop() {
    # do something
    return
}

# 此函数在"停止逻辑之后"执行
post_stop() {
    # do something
    return
}

# 额外状态，如curl测试代理是否ok
extra_status() {
    # do something
    return
}

# 此函数在start的最后一步执行，获取运行时状态(如进程pid)，保存到文件
extra_pid() {
    # 格式同shell变量赋值，注意变量命名，防止冲突/覆盖
    # pid文件是一个shell脚本，下次执行时会source加载它
    # echo "pid_foo=$pid_foo"
    # echo "pid_bar=$pid_bar"
    return
}

###################### 自定义dns方案 ######################

# 自定义dns方案时，你需要自己实现"域名分流"(ignlist/chnlist/gfwlist)
# 并且将相关域名解析出来的ip加入ipset黑/白名单，以便与iptables规则联动
# 黑名单: sstp_black、sstp_black6 | 白名单: sstp_white、sstp_white6

# 以下接口不要求全部实现，你可以根据需要自由组织代码，保证逻辑正确即可
# 如果不知道怎么实现，可以参考ss-tproxy脚本中有关dns的源码，依葫芦画瓢

# 初始化，脚本加载时调用
custom_dns_init() {
    # do something
    return
}

# 要加入白名单的ip，启动dns之前调用
custom_dns_whiteip() {
    # 格式同 ignlist.ext，一行一个
    # echo "-223.5.5.5"
    # echo "~240C::6666"
    return
}

# 要加入黑名单的ip，启动dns之前调用
custom_dns_blackip() {
    # 格式同 gfwlist.ext，一行一个
    # echo "-8.8.8.8"
    # echo "~2001:4860:4860::8888"
    return
}

# 启动dns进程，请务必以dns_procgroup身份运行
custom_dns_start() {
    # do something
    return
}

# 关闭dns进程，stop时调用
custom_dns_stop() {
    # do something
    return
}

# 打印运行状态，status时调用
custom_dns_status() {
    # do something
    return
}

# 清空dns缓存，flush-dnscache时调用
custom_dns_flush() {
    # do something
    return
}

# 此函数在start的最后一步执行，获取运行时状态，同extra_pid
custom_dns_pid() {
    # 格式同shell变量赋值，注意变量命名，防止冲突/覆盖
    # pid文件是一个shell脚本，下次执行时会source加载它
    # echo "pid_foo=$pid_foo"
    # echo "pid_bar=$pid_bar"
    return
}

# 除了上述钩子函数，你还可以定义其他shell函数和变量
# 你也可以在当前文件使用ss-tproxy中已定义的函数和变量
#
# 若定义的函数与ss-tproxy中的同名，则本文件定义的函数覆盖原函数
# 使用自定义dns方案时，此特性可帮助你快速与原脚本融合(见脚本源码)
#
# ss-tproxy.conf是一个shell脚本，可以使用source来加载其他shell脚本
# ss-tproxy.conf被执行时，可以访问ss-tproxy传来的命令行参数(位置参数)

start_hy() {
    # 设置 setgid 权限位 (只需执行一次)
    set_proxy_group hysteria

    (hysteria -c /etc/hysteria/config.json </dev/null &>>/var/log/hysteria.log &)

    sleep 2
}

stop_hy() {
    kill -9 $(pidof hysteria) &>/dev/null
}

··· derekhe@home-proxy-server:/etc/ss-tproxy$ tail -n 3000 /var/log/chinadns.log | grep .storage. 2023-08-04 12:21:46 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#51014 (47347) 2023-08-04 12:21:46 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:21:46 I [main.c:155 handle_local_packet] query [storage.360buyimg.com] from 127.0.0.1#59245 (47349) 2023-08-04 12:21:46 I [main.c:203 handle_local_packet] forward [storage.360buyimg.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:21:46 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (47347), result: accept 2023-08-04 12:21:46 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:21:46 I [main.c:322 handle_remote_packet] reply [storage.360buyimg.com] from 223.5.5.5#53 (47349), result: accept 2023-08-04 12:21:46 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.360buyimg.com] to ipset 2023-08-04 12:22:19 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#45120 (47367) 2023-08-04 12:22:19 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:22:19 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#42232 (47368) 2023-08-04 12:22:19 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:22:19 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (47368), result: accept 2023-08-04 12:22:19 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:22:19 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (47367), result: accept 2023-08-04 12:22:19 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:22:29 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#44859 (15) 2023-08-04 12:22:29 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:22:29 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#49060 (16) 2023-08-04 12:22:29 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:22:29 I [main.c:155 handle_local_packet] query [storage.360buyimg.com] from 127.0.0.1#46236 (19) 2023-08-04 12:22:29 I [main.c:203 handle_local_packet] forward [storage.360buyimg.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:22:29 I [main.c:155 handle_local_packet] query [storage.360buyimg.com] from 127.0.0.1#33940 (20) 2023-08-04 12:22:29 I [main.c:203 handle_local_packet] forward [storage.360buyimg.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:22:29 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (15), result: accept 2023-08-04 12:22:29 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:22:29 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (16), result: accept 2023-08-04 12:22:29 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:22:29 I [main.c:322 handle_remote_packet] reply [storage.360buyimg.com] from 223.5.5.5#53 (19), result: accept 2023-08-04 12:22:29 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.360buyimg.com] to ipset 2023-08-04 12:22:29 I [main.c:322 handle_remote_packet] reply [storage.360buyimg.com] from 223.5.5.5#53 (20), result: accept 2023-08-04 12:22:29 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.360buyimg.com] to ipset 2023-08-04 12:24:36 I [main.c:155 handle_local_packet] query [storage.360buyimg.com] from 127.0.0.1#49901 (95) 2023-08-04 12:24:36 I [main.c:203 handle_local_packet] forward [storage.360buyimg.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:24:36 I [main.c:322 handle_remote_packet] reply [storage.360buyimg.com] from 223.5.5.5#53 (95), result: accept 2023-08-04 12:24:36 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.360buyimg.com] to ipset 2023-08-04 12:29:48 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#59460 (267) 2023-08-04 12:29:48 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:29:48 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#48134 (268) 2023-08-04 12:29:48 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:29:48 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (268), result: accept 2023-08-04 12:29:48 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:29:48 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (267), result: accept 2023-08-04 12:29:48 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:29:56 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#40456 (279) 2023-08-04 12:29:56 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:29:56 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (279), result: accept 2023-08-04 12:29:56 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:30:04 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#38202 (282) 2023-08-04 12:30:04 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:30:04 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#36188 (283) 2023-08-04 12:30:04 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:30:04 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (282), result: accept 2023-08-04 12:30:04 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:30:04 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (283), result: accept 2023-08-04 12:30:04 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:32:32 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#48250 (371) 2023-08-04 12:32:32 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:32:32 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (371), result: accept 2023-08-04 12:32:32 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:32:36 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#39360 (378) 2023-08-04 12:32:36 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:32:36 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#41292 (379) 2023-08-04 12:32:36 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:32:36 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (378), result: accept 2023-08-04 12:32:36 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:32:36 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (379), result: accept 2023-08-04 12:32:36 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:32:49 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#42161 (380) 2023-08-04 12:32:49 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:32:49 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#36967 (381) 2023-08-04 12:32:49 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:32:49 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (380), result: accept 2023-08-04 12:32:49 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:32:49 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (381), result: accept 2023-08-04 12:32:49 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:32:50 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#58943 (382) 2023-08-04 12:32:50 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:32:50 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#49914 (383) 2023-08-04 12:32:50 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:32:50 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (382), result: accept 2023-08-04 12:32:50 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:32:50 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (383), result: accept 2023-08-04 12:32:50 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:32:50 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#34533 (384) 2023-08-04 12:32:50 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:32:50 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#43142 (385) 2023-08-04 12:32:50 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:32:50 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (384), result: accept 2023-08-04 12:32:50 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:32:50 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (385), result: accept 2023-08-04 12:32:50 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:32:50 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#51068 (386) 2023-08-04 12:32:50 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:32:50 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#40061 (387) 2023-08-04 12:32:50 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:32:50 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (386), result: accept 2023-08-04 12:32:50 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:32:50 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (387), result: accept 2023-08-04 12:32:50 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:32:50 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#54067 (388) 2023-08-04 12:32:50 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:32:50 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#37832 (389) 2023-08-04 12:32:50 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:32:50 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (388), result: accept 2023-08-04 12:32:50 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:32:50 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (389), result: accept 2023-08-04 12:32:50 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:32:52 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#56212 (393) 2023-08-04 12:32:52 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:32:52 I [main.c:155 handle_local_packet] query [storage.jd.com] from 127.0.0.1#53624 (394) 2023-08-04 12:32:52 I [main.c:203 handle_local_packet] forward [storage.jd.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:32:52 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (393), result: accept 2023-08-04 12:32:52 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:32:52 I [main.c:322 handle_remote_packet] reply [storage.jd.com] from 223.5.5.5#53 (394), result: accept 2023-08-04 12:32:52 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.jd.com] to ipset 2023-08-04 12:33:02 I [main.c:155 handle_local_packet] query [storage.360buyimg.com] from 127.0.0.1#48267 (455) 2023-08-04 12:33:02 I [main.c:203 handle_local_packet] forward [storage.360buyimg.com] to 223.5.5.5#53 (chinadns) 2023-08-04 12:33:02 I [main.c:322 handle_remote_packet] reply [storage.360buyimg.com] from 223.5.5.5#53 (455), result: accept 2023-08-04 12:33:02 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [storage.360buyimg.com] to ipset ···

image
derekhe commented 1 year ago

搜索github的话，会发现很多和京东相关的问题：https://github.com/search?q=jd.com+dns&type=issues

zfl9 commented 1 year ago

看了chinadns-ng日志，出问题的storage.jd.com域名，并没有所谓的dns解析问题，该域名被判定为tag:chn（这是正确的），转发给223.5.5.5，解析也正常，并未超时等情况。

另外，我刚回家，使用 ss-tproxy chnroute 模式，在 Chrome 下测试访问 jd.com 正常，并未出现你说的加载不了的问题。

zfl9 commented 1 year ago

是不是浏览器有什么设置，或者插件导致的。

换个其他浏览器看看？或者无痕模式看看。

cattyhouse commented 1 year ago

223.5.5.5 把京东的部分域名污染了, 解析成了别的ip... 试试国内用 119.29.29.29 或者 114

zfl9 commented 1 year ago

223.5.5.5 把京东的部分域名污染了, 解析成了别的ip... 试试国内用 119.29.29.29 或者 114

有这个可能，改一下 dns_direct，改为 119 或者 114（记得清空 dns 缓存） @derekhe

ak1ra-komj commented 1 year ago

我也遭遇到 京东 的访问性问题了, 正在犹豫是否该向这边提 issue, 发现有人提了, 我补充下我整理的现象,

在没有添加 chinadns_extra_options 选项禁用 chinadns-ng 的 IPv6 返回时, curl 会尝试连接 2409:8c38:c50:603:8000::3 这个 IP 地址, 另外还有个无法连接的 IPv4 地址 117.72.226.3

下面是 curl 和 dig 时 dnsmasq 和 chinadns-ng 的输出,

root@ss-tproxy:~# curl -vL https://www.jd.com
*   Trying 117.72.226.3:443...
*   Trying [2409:8c38:c50:603:8000::3]:443...
* Immediate connect fail for 2409:8c38:c50:603:8000::3: Network is unreachable

$ nali 117.72.226.3
117.72.226.3 [北京市 方正宽带]

$ nali 2409:8c38:c50:603:8000::3
2409:8c38:c50:603:8000::3 [中国 江西省 中国移动IDC]

尝试使用 dig 查询 DNS 解析,

root@ss-tproxy:~# /usr/bin/dig +nocmd +noall +answer www.jd.com
www.jd.com.             14      IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 14 IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 14 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    14      IN      A       117.72.226.3

Aug  4 01:54:04 dnsmasq[12188]: query[A] www.jd.com from 127.0.0.1
Aug  4 01:54:04 dnsmasq[12188]: forwarded www.jd.com to 127.0.0.1#65353
Aug  4 01:54:04 dnsmasq[12188]: reply www.jd.com is <CNAME>
Aug  4 01:54:04 dnsmasq[12188]: reply www.jd.com.gslb.qianxun.com is <CNAME>
Aug  4 01:54:04 dnsmasq[12188]: reply www.jd.com.s.galileo.jcloud-cdn.com is <CNAME>
Aug  4 01:54:04 dnsmasq[12188]: reply wwwv6.jcloudimg.com is 117.72.226.3

2023-08-04 01:54:04 I [main.c:155 handle_local_packet] query [www.jd.com] from 127.0.0.1#46868 (0)
2023-08-04 01:54:04 I [main.c:203 handle_local_packet] forward [www.jd.com] to 223.5.5.5#53 (chinadns)
2023-08-04 01:54:04 I [main.c:322 handle_remote_packet] reply [www.jd.com] from 223.5.5.5#53 (0), result: accept
2023-08-04 01:54:04 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [www.jd.com] to ipset

使用 dig 查询 AAAA 解析,

root@ss-tproxy:~# /usr/bin/dig +nocmd +noall +answer www.jd.com AAAA
www.jd.com.             1       IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 1  IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 1 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    1       IN      AAAA    2409:8c38:c50:603:8000::3

Aug  4 01:54:08 dnsmasq[12188]: query[AAAA] www.jd.com from 127.0.0.1
Aug  4 01:54:08 dnsmasq[12188]: forwarded www.jd.com to 127.0.0.1#65353
Aug  4 01:54:08 dnsmasq[12188]: reply www.jd.com is <CNAME>
Aug  4 01:54:08 dnsmasq[12188]: reply www.jd.com.gslb.qianxun.com is <CNAME>
Aug  4 01:54:08 dnsmasq[12188]: reply www.jd.com.s.galileo.jcloud-cdn.com is <CNAME>
Aug  4 01:54:08 dnsmasq[12188]: reply wwwv6.jcloudimg.com is 2409:8c38:c50:603:8000::3

2023-08-04 01:54:08 I [main.c:155 handle_local_packet] query [www.jd.com] from 127.0.0.1#59579 (1)
2023-08-04 01:54:08 I [main.c:203 handle_local_packet] forward [www.jd.com] to 223.5.5.5#53 (chinadns)
2023-08-04 01:54:08 I [main.c:322 handle_remote_packet] reply [www.jd.com] from 223.5.5.5#53 (1), result: accept
2023-08-04 01:54:08 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [www.jd.com] to ipset

第一个 CNAME 响应看到个奇怪的域名 www.jd.com.gslb.qianxun.com, 查询了下 whois 注册信息确实是京东的, NS 记录也显示来自 jdcache.com,

Registrant Organization: 北京京东叁佰陆拾度电子商务有限公司
Registrant State/Province: 北京市
Registrant Country: CN
Registrant Email: Select Request Email Form at https://domains.markmonitor.com/whois/qianxun.com

ns1.jdcache.com
ns2.jdcache.com
ns3.jdcache.com
ns4.jdcache.com
ns5.jdcache.com

chinadns-ng 加上 --no-ipv6 actCT 选项后, 最终解析的 IP 地址仍然是错的, 只是不会有 AAAA 响应,

Aug  4 01:24:57 dnsmasq[10747]: query[A] www.jd.com from 127.0.0.1
Aug  4 01:24:57 dnsmasq[10747]: forwarded www.jd.com to 127.0.0.1#65353
Aug  4 01:24:57 dnsmasq[10747]: query[AAAA] www.jd.com from 127.0.0.1
Aug  4 01:24:57 dnsmasq[10747]: forwarded www.jd.com to 127.0.0.1#65353
Aug  4 01:24:57 dnsmasq[10747]: reply www.jd.com is NODATA-IPv6
Aug  4 01:24:57 dnsmasq[10747]: reply www.jd.com is <CNAME>
Aug  4 01:24:57 dnsmasq[10747]: reply www.jd.com.gslb.qianxun.com is <CNAME>
Aug  4 01:24:57 dnsmasq[10747]: reply www.jd.com.s.galileo.jcloud-cdn.com is <CNAME>
Aug  4 01:24:57 dnsmasq[10747]: reply wwwv6.jcloudimg.com is 117.72.226.3

2023-08-04 01:24:57 I [main.c:155 handle_local_packet] query [www.jd.com] from 127.0.0.1#53439 (4)
2023-08-04 01:24:57 I [main.c:203 handle_local_packet] forward [www.jd.com] to 223.5.5.5#53 (chinadns)
2023-08-04 01:24:57 I [main.c:155 handle_local_packet] query [www.jd.com] from 127.0.0.1#50703 (5)
2023-08-04 01:24:57 I [main.c:161 handle_local_packet] filter [www.jd.com] AAAA query, rule: all
2023-08-04 01:24:57 I [main.c:322 handle_remote_packet] reply [www.jd.com] from 223.5.5.5#53 (4), result: accept
2023-08-04 01:24:57 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [www.jd.com] to ipset

把"涉事"的几个域名添加到 gfwlist.ext 中后,

@jd.com
@qianxun.com
@jcloud-cdn.com
@jcloudimg.com

DNS 解析被放到了 dns_remote=8.8.8.8#53, 解析是正确的, 只不过没那么 CDN 友好了, 解析的地址为最靠近代理 IP 的 CDN 节点, 比如我这里到了 香港 网宿科技CDN节点

root@ss-tproxy:~# /usr/bin/dig +nocmd +noall +answer www.jd.com
www.jd.com.             3595    IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 3595 IN    CNAME   jd-abroad.cdn20.com.
jd-abroad.cdn20.com.    3595    IN      A       163.171.193.139

$ nali 163.171.193.139
163.171.193.139 [香港 网宿科技CDN节点]

Aug  4 02:27:34 dnsmasq[12820]: query[A] www.jd.com from 127.0.0.1
Aug  4 02:27:34 dnsmasq[12820]: forwarded www.jd.com to 127.0.0.1#65353
Aug  4 02:27:35 dnsmasq[12820]: reply www.jd.com is <CNAME>
Aug  4 02:27:35 dnsmasq[12820]: reply www.jd.com.gslb.qianxun.com is <CNAME>
Aug  4 02:27:35 dnsmasq[12820]: reply jd-abroad.cdn20.com is 163.171.193.139

2023-08-04 02:27:34 I [main.c:155 handle_local_packet] query [www.jd.com] from 127.0.0.1#54564 (0)
2023-08-04 02:27:34 I [main.c:203 handle_local_packet] forward [www.jd.com] to 8.8.8.8#53 (trustdns)
2023-08-04 02:27:35 I [main.c:342 handle_remote_packet] reply [www.jd.com] from 8.8.8.8#53 (0), result: accept
2023-08-04 02:27:35 I [main.c:344 handle_remote_packet] add the answer ip of name-tag:gfw [www.jd.com] to ipset

在 PC 上在不经过 ss-tproxy 时直接指定 nameserver 时解析一切正常, 非常奇怪...

$ /usr/bin/dig @1.1.1.1 +nocmd +noall +answer www.jd.com | nali
www.jd.com.             2       IN      CNAME   www.jd.com.gslb.qianxun.com [京东云 CDN] .
www.jd.com.gslb.qianxun.com [京东云 CDN] . 2    IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com [京东云 CDN] .
www.jd.com.s.galileo.jcloud-cdn.com [京东云 CDN] . 2 IN CNAME   wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    2       IN      A       27.36.125.x [广东省佛山市 联通]

$ /usr/bin/dig @223.5.5.5 +nocmd +noall +answer www.jd.com | nali
www.jd.com.             45      IN      CNAME   www.jd.com.gslb.qianxun.com [京东云 CDN] .
www.jd.com.gslb.qianxun.com [京东云 CDN] . 45   IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com [京东云 CDN] .
www.jd.com.s.galileo.jcloud-cdn.com [京东云 CDN] . 45   IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    45      IN      A       27.36.125.x [广东省佛山市 联通]

总结一下,

本地解析结果与通过 chinadns-ng 走 阿里云 DNS 解析时, 前面几个 CNAME 都是一致的, 只是在把最后的 CDN 域名 wwwv6.jcloudimg.com 解析到最终 IP 时出了问题,

不过中间 www.jd.com.s.galileo.jcloud-cdn.com. -> wwwv6.jcloudimg.com. 这条 CNAME 解析就挺奇怪的, 解析到一个看起来是 IPv6 的子域名 wwwv6., 这部分是京东自己的 DNS 配置问题? 还是说它错误地认为我的网络支持 IPv6 然后给了我 IPv6 的 CNAME 域名? 实际上我的 ISP 没有分配 IPv6 地址.

通过 chinadns-ng 走阿里云 DNS 时解析出错误的 IP 地址这部分是 阿里云 DNS 的问题? 京东这个域名被污染了? 还是确实是京东 CDN 节点之一, 只是节点挂了... 怀疑 阿里云 DNS 劣化竞品网站访问体验大概没什么道理, 不走 ss-tproxy 的 chinadns-ng 时一切正常, 或许可以切换别的国内公共 DNS 或者干脆用运营商 DNS 试试? 运营商 DNS 自然是 CDN 最友好的... 不知道 chinadns-ng 在向 --china-dns 请求 DNS 查询时有没有带什么额外的参数? 会是 chinadns-ng 的问题吗?

Update 2023-08-04 22:40

尝试了修改 dns_direct 为 DNSPod 119.29.29.29, dns_remote 为 Cloudflare 1.0.0.1,

经过 chinadns-ng 时的 www.jd.com 的解析结果仍然跟上面一致, 仍然会出现两个"错误"的 IP 地址, 下面是我的配置文件与默认配置的区别,

$ diff ss-tproxy.default.conf ss-tproxy.conf
89,90c89,90
< dns_direct='223.5.5.5#53'             # 直连DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
< dns_direct6='240C::6666#53'           # 直连DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
---
> dns_direct='119.29.29.29#53'          # 直连DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
> dns_direct6='2402:4e00::#53'          # 直连DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
94,95c94,95
< dns_remote='8.8.8.8#53'               # 远程DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
< dns_remote6='2001:4860:4860::8888#53' # 远程DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
---
> dns_remote='1.0.0.1#53'               # 远程DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
> dns_remote6='2606:4700:4700::1001#53' # 远程DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
106c106
< dnsmasq_log_enable='false'              # 记录详细日志，除非进行调试，否则不建议启用
---
> dnsmasq_log_enable='true'               # 记录详细日志，除非进行调试，否则不建议启用
118c118
< chinadns_verbose='false'                 # 记录详细日志，除非进行调试，否则不建议启用
---
> chinadns_verbose='true'                  # 记录详细日志，除非进行调试，否则不建议启用
135c135
< ipts_set_snat='false'               # 设置 ipv4 MASQUERADE(SNAT) 规则，selfonly=false 时有效，详见 README
---
> ipts_set_snat='true'                # 设置 ipv4 MASQUERADE(SNAT) 规则，selfonly=false 时有效，详见 README
derekhe commented 1 year ago

对，如果不走chinadns-ng就没问题。

zfl9 commented 1 year ago

我也遭遇到 京东 的访问性问题了, 正在犹豫是否该向这边提 issue, 发现有人提了, 我补充下我整理的现象,

在没有添加 chinadns_extra_options 选项禁用 chinadns-ng 的 IPv6 返回时, curl 会尝试连接 2409:8c38:c50:603:8000::3 这个 IP 地址, 另外还有个无法连接的 IPv4 地址 117.72.226.3

下面是 curl 和 dig 时 dnsmasq 和 chinadns-ng 的输出,

root@ss-tproxy:~# curl -vL https://www.jd.com
*   Trying 117.72.226.3:443...
*   Trying [2409:8c38:c50:603:8000::3]:443...
* Immediate connect fail for 2409:8c38:c50:603:8000::3: Network is unreachable

$ nali 117.72.226.3
117.72.226.3 [北京市 方正宽带]

$ nali 2409:8c38:c50:603:8000::3
2409:8c38:c50:603:8000::3 [中国 江西省 中国移动IDC]

尝试使用 dig 查询 DNS 解析,

root@ss-tproxy:~# /usr/bin/dig +nocmd +noall +answer www.jd.com
www.jd.com.             14      IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 14 IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 14 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    14      IN      A       117.72.226.3

Aug  4 01:54:04 dnsmasq[12188]: query[A] www.jd.com from 127.0.0.1
Aug  4 01:54:04 dnsmasq[12188]: forwarded www.jd.com to 127.0.0.1#65353
Aug  4 01:54:04 dnsmasq[12188]: reply www.jd.com is <CNAME>
Aug  4 01:54:04 dnsmasq[12188]: reply www.jd.com.gslb.qianxun.com is <CNAME>
Aug  4 01:54:04 dnsmasq[12188]: reply www.jd.com.s.galileo.jcloud-cdn.com is <CNAME>
Aug  4 01:54:04 dnsmasq[12188]: reply wwwv6.jcloudimg.com is 117.72.226.3

2023-08-04 01:54:04 I [main.c:155 handle_local_packet] query [www.jd.com] from 127.0.0.1#46868 (0)
2023-08-04 01:54:04 I [main.c:203 handle_local_packet] forward [www.jd.com] to 223.5.5.5#53 (chinadns)
2023-08-04 01:54:04 I [main.c:322 handle_remote_packet] reply [www.jd.com] from 223.5.5.5#53 (0), result: accept
2023-08-04 01:54:04 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [www.jd.com] to ipset

使用 dig 查询 AAAA 解析,

root@ss-tproxy:~# /usr/bin/dig +nocmd +noall +answer www.jd.com AAAA
www.jd.com.             1       IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 1  IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 1 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    1       IN      AAAA    2409:8c38:c50:603:8000::3

Aug  4 01:54:08 dnsmasq[12188]: query[AAAA] www.jd.com from 127.0.0.1
Aug  4 01:54:08 dnsmasq[12188]: forwarded www.jd.com to 127.0.0.1#65353
Aug  4 01:54:08 dnsmasq[12188]: reply www.jd.com is <CNAME>
Aug  4 01:54:08 dnsmasq[12188]: reply www.jd.com.gslb.qianxun.com is <CNAME>
Aug  4 01:54:08 dnsmasq[12188]: reply www.jd.com.s.galileo.jcloud-cdn.com is <CNAME>
Aug  4 01:54:08 dnsmasq[12188]: reply wwwv6.jcloudimg.com is 2409:8c38:c50:603:8000::3

2023-08-04 01:54:08 I [main.c:155 handle_local_packet] query [www.jd.com] from 127.0.0.1#59579 (1)
2023-08-04 01:54:08 I [main.c:203 handle_local_packet] forward [www.jd.com] to 223.5.5.5#53 (chinadns)
2023-08-04 01:54:08 I [main.c:322 handle_remote_packet] reply [www.jd.com] from 223.5.5.5#53 (1), result: accept
2023-08-04 01:54:08 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [www.jd.com] to ipset

第一个 CNAME 响应看到个奇怪的域名 www.jd.com.gslb.qianxun.com, 查询了下 whois 注册信息确实是京东的, NS 记录也显示来自 jdcache.com,

Registrant Organization: 北京京东叁佰陆拾度电子商务有限公司
Registrant State/Province: 北京市
Registrant Country: CN
Registrant Email: Select Request Email Form at https://domains.markmonitor.com/whois/qianxun.com

ns1.jdcache.com
ns2.jdcache.com
ns3.jdcache.com
ns4.jdcache.com
ns5.jdcache.com

chinadns-ng 加上 --no-ipv6 actCT 选项后, 最终解析的 IP 地址仍然是错的, 只是不会有 AAAA 响应,

Aug  4 01:24:57 dnsmasq[10747]: query[A] www.jd.com from 127.0.0.1
Aug  4 01:24:57 dnsmasq[10747]: forwarded www.jd.com to 127.0.0.1#65353
Aug  4 01:24:57 dnsmasq[10747]: query[AAAA] www.jd.com from 127.0.0.1
Aug  4 01:24:57 dnsmasq[10747]: forwarded www.jd.com to 127.0.0.1#65353
Aug  4 01:24:57 dnsmasq[10747]: reply www.jd.com is NODATA-IPv6
Aug  4 01:24:57 dnsmasq[10747]: reply www.jd.com is <CNAME>
Aug  4 01:24:57 dnsmasq[10747]: reply www.jd.com.gslb.qianxun.com is <CNAME>
Aug  4 01:24:57 dnsmasq[10747]: reply www.jd.com.s.galileo.jcloud-cdn.com is <CNAME>
Aug  4 01:24:57 dnsmasq[10747]: reply wwwv6.jcloudimg.com is 117.72.226.3

2023-08-04 01:24:57 I [main.c:155 handle_local_packet] query [www.jd.com] from 127.0.0.1#53439 (4)
2023-08-04 01:24:57 I [main.c:203 handle_local_packet] forward [www.jd.com] to 223.5.5.5#53 (chinadns)
2023-08-04 01:24:57 I [main.c:155 handle_local_packet] query [www.jd.com] from 127.0.0.1#50703 (5)
2023-08-04 01:24:57 I [main.c:161 handle_local_packet] filter [www.jd.com] AAAA query, rule: all
2023-08-04 01:24:57 I [main.c:322 handle_remote_packet] reply [www.jd.com] from 223.5.5.5#53 (4), result: accept
2023-08-04 01:24:57 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [www.jd.com] to ipset

把"涉事"的几个域名添加到 gfwlist.ext 中后,

@jd.com
@qianxun.com
@jcloud-cdn.com
@jcloudimg.com

DNS 解析被放到了 dns_remote=8.8.8.8#53, 解析是正确的, 只不过没那么 CDN 友好了, 解析的地址为最靠近代理 IP 的 CDN 节点, 比如我这里到了 香港 网宿科技CDN节点

root@ss-tproxy:~# /usr/bin/dig +nocmd +noall +answer www.jd.com
www.jd.com.             3595    IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 3595 IN    CNAME   jd-abroad.cdn20.com.
jd-abroad.cdn20.com.    3595    IN      A       163.171.193.139

$ nali 163.171.193.139
163.171.193.139 [香港 网宿科技CDN节点]

Aug  4 02:27:34 dnsmasq[12820]: query[A] www.jd.com from 127.0.0.1
Aug  4 02:27:34 dnsmasq[12820]: forwarded www.jd.com to 127.0.0.1#65353
Aug  4 02:27:35 dnsmasq[12820]: reply www.jd.com is <CNAME>
Aug  4 02:27:35 dnsmasq[12820]: reply www.jd.com.gslb.qianxun.com is <CNAME>
Aug  4 02:27:35 dnsmasq[12820]: reply jd-abroad.cdn20.com is 163.171.193.139

2023-08-04 02:27:34 I [main.c:155 handle_local_packet] query [www.jd.com] from 127.0.0.1#54564 (0)
2023-08-04 02:27:34 I [main.c:203 handle_local_packet] forward [www.jd.com] to 8.8.8.8#53 (trustdns)
2023-08-04 02:27:35 I [main.c:342 handle_remote_packet] reply [www.jd.com] from 8.8.8.8#53 (0), result: accept
2023-08-04 02:27:35 I [main.c:344 handle_remote_packet] add the answer ip of name-tag:gfw [www.jd.com] to ipset

在 PC 上在不经过 ss-tproxy 时直接指定 nameserver 时解析一切正常, 非常奇怪...

$ /usr/bin/dig @1.1.1.1 +nocmd +noall +answer www.jd.com | nali
www.jd.com.             2       IN      CNAME   www.jd.com.gslb.qianxun.com [京东云 CDN] .
www.jd.com.gslb.qianxun.com [京东云 CDN] . 2    IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com [京东云 CDN] .
www.jd.com.s.galileo.jcloud-cdn.com [京东云 CDN] . 2 IN CNAME   wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    2       IN      A       27.36.125.x [广东省佛山市 联通]

$ /usr/bin/dig @223.5.5.5 +nocmd +noall +answer www.jd.com | nali
www.jd.com.             45      IN      CNAME   www.jd.com.gslb.qianxun.com [京东云 CDN] .
www.jd.com.gslb.qianxun.com [京东云 CDN] . 45   IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com [京东云 CDN] .
www.jd.com.s.galileo.jcloud-cdn.com [京东云 CDN] . 45   IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    45      IN      A       27.36.125.x [广东省佛山市 联通]

总结一下,

本地解析结果与通过 chinadns-ng 走 阿里云 DNS 解析时, 前面几个 CNAME 都是一致的, 只是在把最后的 CDN 域名 wwwv6.jcloudimg.com 解析到最终 IP 时出了问题,

不过中间 www.jd.com.s.galileo.jcloud-cdn.com. -> wwwv6.jcloudimg.com. 这条 CNAME 解析就挺奇怪的, 解析到一个看起来是 IPv6 的子域名 wwwv6., 这部分是京东自己的 DNS 配置问题? 还是说它错误地认为我的网络支持 IPv6 然后给了我 IPv6 的 CNAME 域名? 实际上我的 ISP 没有分配 IPv6 地址.

通过 chinadns-ng 走阿里云 DNS 时解析出错误的 IP 地址这部分是 阿里云 DNS 的问题? 京东这个域名被污染了? 还是确实是京东 CDN 节点之一, 只是节点挂了... 怀疑 阿里云 DNS 劣化竞品网站访问体验大概没什么道理, 不走 ss-tproxy 的 chinadns-ng 时一切正常, 或许可以切换别的国内公共 DNS 或者干脆用运营商 DNS 试试? 运营商 DNS 自然是 CDN 最友好的... 不知道 chinadns-ng 在向 --china-dns 请求 DNS 查询时有没有带什么额外的参数? 会是 chinadns-ng 的问题吗?

Update 2023-08-04 22:40

尝试了修改 dns_direct 为 DNSPod 119.29.29.29, dns_remote 为 Cloudflare 1.0.0.1,

经过 chinadns-ng 时的 www.jd.com 的解析结果仍然跟上面一致, 仍然会出现两个"错误"的 IP 地址, 下面是我的配置文件与默认配置的区别,

$ diff ss-tproxy.default.conf ss-tproxy.conf
89,90c89,90
< dns_direct='223.5.5.5#53'             # 直连DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
< dns_direct6='240C::6666#53'           # 直连DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
---
> dns_direct='119.29.29.29#53'          # 直连DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
> dns_direct6='2402:4e00::#53'          # 直连DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
94,95c94,95
< dns_remote='8.8.8.8#53'               # 远程DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
< dns_remote6='2001:4860:4860::8888#53' # 远程DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
---
> dns_remote='1.0.0.1#53'               # 远程DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
> dns_remote6='2606:4700:4700::1001#53' # 远程DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
106c106
< dnsmasq_log_enable='false'              # 记录详细日志，除非进行调试，否则不建议启用
---
> dnsmasq_log_enable='true'               # 记录详细日志，除非进行调试，否则不建议启用
118c118
< chinadns_verbose='false'                 # 记录详细日志，除非进行调试，否则不建议启用
---
> chinadns_verbose='true'                  # 记录详细日志，除非进行调试，否则不建议启用
135c135
< ipts_set_snat='false'               # 设置 ipv4 MASQUERADE(SNAT) 规则，selfonly=false 时有效，详见 README
---
> ipts_set_snat='true'                # 设置 ipv4 MASQUERADE(SNAT) 规则，selfonly=false 时有效，详见 README

我说明几点：

zfl9 commented 1 year ago

如果怀疑经过 chinadns-ng 的解析结果与 直接访问 china 上游的解析结果不同，最好贴出 dig 对比测试结果。如：

请确保这两个测试使用的国内 DNS 上游相同，不然没有意义。

ak1ra-komj commented 1 year ago

如果怀疑经过 chinadns-ng 的解析结果与 直接访问 china 上游的解析结果不同，最好贴出 dig 对比测试结果。如：

  • 直接查询，假设 dns 为 114.114.114.114，dig @114.114.114.114 jd.com
  • 经过chinadns-ng，确保 china 上游与上面的相同（114），dig @127.0.0.1 -p65353 jd.com

请确保这两个测试使用的国内 DNS 上游相同，不然没有意义。

上面的记录中有 dig 直接使用阿里云 DNS 与经过 chinadns-ng 的结果，后面也测试了 DNSPod 的结果，这里没贴出来，我可以补充上。

zfl9 commented 1 year ago

如果怀疑经过 chinadns-ng 的解析结果与 直接访问 china 上游的解析结果不同，最好贴出 dig 对比测试结果。如：

  • 直接查询，假设 dns 为 114.114.114.114，dig @114.114.114.114 jd.com
  • 经过chinadns-ng，确保 china 上游与上面的相同（114），dig @127.0.0.1 -p65353 jd.com

请确保这两个测试使用的国内 DNS 上游相同，不然没有意义。

上面的记录中有 dig 直接使用阿里云 DNS 与经过 chinadns-ng 的结果，后面也测试了 DNSPod 的结果，这里没贴出来，我可以补充上。

那有请~

cattyhouse commented 1 year ago

换了 DNS 之后, 还要清空透明代理的缓存, 还要清空你的手机/电脑的缓存 (一般可以 关->开 Wi-Fi/飞行模式等, 清空缓存)

ak1ra-komj commented 1 year ago

如果怀疑经过 chinadns-ng 的解析结果与 直接访问 china 上游的解析结果不同，最好贴出 dig 对比测试结果。如：

  • 直接查询，假设 dns 为 114.114.114.114，dig @114.114.114.114 jd.com
  • 经过chinadns-ng，确保 china 上游与上面的相同（114），dig @127.0.0.1 -p65353 jd.com

请确保这两个测试使用的国内 DNS 上游相同，不然没有意义。

上面的记录中有 dig 直接使用阿里云 DNS 与经过 chinadns-ng 的结果，后面也测试了 DNSPod 的结果，这里没贴出来，我可以补充上。

那有请~

部署 ss-tproxy 的主机操作系统为 Debian 12 (bookworm),

下面是 dns_direct 配置为 DNSPod 时, 在部署 ss-tproxy 的虚拟机和本地的 dig 结果,

root@ss-tproxy:/etc/ss-tproxy# diff ss-tproxy.default.conf ss-tproxy.conf
89,90c89,90
< dns_direct='223.5.5.5#53'             # 直连DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
< dns_direct6='240C::6666#53'           # 直连DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
---
> dns_direct='119.29.29.29#53'          # 直连DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
> dns_direct6='2402:4e00::#53'          # 直连DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
94,95c94,95
< dns_remote='8.8.8.8#53'               # 远程DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
< dns_remote6='2001:4860:4860::8888#53' # 远程DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
---
> dns_remote='1.0.0.1#53'               # 远程DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
> dns_remote6='2606:4700:4700::1001#53' # 远程DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器

root@ss-tproxy:/etc/ss-tproxy# dig +nocmd +noall +answer www.jd.com
www.jd.com.             3539    IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 3539 IN    CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 3539 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    3539    IN      A       117.72.226.3

root@ss-tproxy:/etc/ss-tproxy# dig +nocmd +noall +answer www.jd.com AAAA
www.jd.com.             120     IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 60 IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 60 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    120     IN      AAAA    2409:8c38:c50:603:8000::3

下面是同样使用 DNSPod 时本地不经过 ss-tproxy 代理的结果

$ dig @119.29.29.29 +nocmd +noall +answer www.jd.com | nali
www.jd.com.             1       IN      CNAME   www.jd.com.gslb.qianxun.com [京东云 CDN] .
www.jd.com.gslb.qianxun.com [京东云 CDN] . 1    IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com [京东云 CDN] .
www.jd.com.s.galileo.jcloud-cdn.com [京东云 CDN] . 1 IN CNAME   wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    1       IN      A       27.36.125.x [广东省佛山市 联通]

下面是 dns_direct 配置为 114 DNS 时, 在部署 ss-tproxy 的虚拟机和本地的的 dig 结果,

root@ss-tproxy:/etc/ss-tproxy# diff ss-tproxy.default.conf ss-tproxy.conf
89,90c89,90
< dns_direct='223.5.5.5#53'             # 直连DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
< dns_direct6='240C::6666#53'           # 直连DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
---
> dns_direct='114.114.114.114#53'       # 直连DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
> dns_direct6='2402:4e00::#53'          # 直连DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
94,95c94,95
< dns_remote='8.8.8.8#53'               # 远程DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
< dns_remote6='2001:4860:4860::8888#53' # 远程DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
---
> dns_remote='1.0.0.1#53'               # 远程DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
> dns_remote6='2606:4700:4700::1001#53' # 远程DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器

root@ss-tproxy:/etc/ss-tproxy# dig +nocmd +noall +answer www.jd.com
www.jd.com.             54      IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 39 IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 39 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    39      IN      A       27.36.125.x

root@ss-tproxy:/etc/ss-tproxy# dig +nocmd +noall +answer www.jd.com AAAA
www.jd.com.             27      IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 20 IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 20 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    27      IN      AAAA    2408:8756:4cff:d001:x::3

本地,

$ dig @114.114.114.114 +nocmd +noall +answer www.jd.com | nali
www.jd.com.             1       IN      CNAME   www.jd.com.gslb.qianxun.com [京东云 CDN] .
www.jd.com.gslb.qianxun.com [京东云 CDN] . 1    IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com [京东云 CDN] .
www.jd.com.s.galileo.jcloud-cdn.com [京东云 CDN] . 1 IN CNAME   wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    1       IN      A       27.36.125.x [广东省佛山市 联通]

114 DNS 的解析结果居然是对的...

换了 DNS 之后, 还要清空透明代理的缓存, 还要清空你的手机/电脑的缓存 (一般可以 关->开 Wi-Fi/飞行模式等, 清空缓存)

每次修改过配置文件都执行过 ss-tproxy restart 的, 最上面进行 dig 查询时也都进行过 ss-tproxy flush-dns 操作的.

zfl9 commented 1 year ago

在使用 119.29.29.29 的时候，dig @127.0.0.1 -p65353 www.jd.com 看看结果，发出来

cattyhouse commented 1 year ago

dig www.jd.com 没有意义. 因为打不开的通常是京东后台的字域名, 而不是 www.jd.com. 能否打开你想要访问的京东服务, 用手机测试.

ak1ra-komj commented 1 year ago

在使用 119.29.29.29 的时候，dig @127.0.0.1 -p65353 www.jd.com 看看结果，发出来

root@ss-tproxy:/etc/ss-tproxy# ss-tproxy flush-dns
root@ss-tproxy:/etc/ss-tproxy# dig @127.0.0.1 -p65353 www.jd.com

; <<>> DiG 9.18.16-1~deb12u1-Debian <<>> @127.0.0.1 -p65353 www.jd.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64268
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: aadc2dc87209a2b5 (echoed)
;; QUESTION SECTION:
;www.jd.com.                    IN      A

;; ANSWER SECTION:
www.jd.com.             63      IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 18 IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 18 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    18      IN      A       117.72.226.3

;; Query time: 12 msec
;; SERVER: 127.0.0.1#65353(127.0.0.1) (UDP)
;; WHEN: Sat Aug 05 00:10:02 HKT 2023
;; MSG SIZE  rcvd: 181

root@ss-tproxy:/etc/ss-tproxy# tail -n20 /var/log/chinadns.log
2023-08-05 00:09:05 I [main.c:203 handle_local_packet] forward [www.jd.com] to 119.29.29.29#53 (chinadns)
2023-08-05 00:09:05 I [main.c:322 handle_remote_packet] reply [www.jd.com] from 119.29.29.29#53 (2), result: accept
2023-08-05 00:09:05 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [www.jd.com] to ipset
2023-08-05 00:09:08 I [main.c:155 handle_local_packet] query [www.jd.com] from 127.0.0.1#46338 (3)
2023-08-05 00:09:08 I [main.c:203 handle_local_packet] forward [www.jd.com] to 119.29.29.29#53 (chinadns)
2023-08-05 00:09:08 I [main.c:322 handle_remote_packet] reply [www.jd.com] from 119.29.29.29#53 (3), result: accept
2023-08-05 00:09:08 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [www.jd.com] to ipset
2023-08-05 00:09:27 I [main.c:155 handle_local_packet] query [www.jd.com] from 127.0.0.1#41911 (4)
2023-08-05 00:09:27 I [main.c:96 update_upstream_sock] create new socket, old socket is used for 72 seconds
2023-08-05 00:09:27 I [main.c:203 handle_local_packet] forward [www.jd.com] to 119.29.29.29#53 (chinadns)
2023-08-05 00:09:27 I [main.c:322 handle_remote_packet] reply [www.jd.com] from 119.29.29.29#53 (4), result: accept
2023-08-05 00:09:27 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [www.jd.com] to ipset
2023-08-05 00:09:32 I [main.c:155 handle_local_packet] query [www.jd.com] from 127.0.0.1#44123 (5)
2023-08-05 00:09:32 I [main.c:203 handle_local_packet] forward [www.jd.com] to 119.29.29.29#53 (chinadns)
2023-08-05 00:09:32 I [main.c:322 handle_remote_packet] reply [www.jd.com] from 119.29.29.29#53 (5), result: accept
2023-08-05 00:09:32 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [www.jd.com] to ipset
2023-08-05 00:10:02 I [main.c:155 handle_local_packet] query [www.jd.com] from 127.0.0.1#52086 (6)
2023-08-05 00:10:02 I [main.c:203 handle_local_packet] forward [www.jd.com] to 119.29.29.29#53 (chinadns)
2023-08-05 00:10:02 I [main.c:322 handle_remote_packet] reply [www.jd.com] from 119.29.29.29#53 (6), result: accept
2023-08-05 00:10:02 I [main.c:326 handle_remote_packet] add the answer ip of name-tag:chn [www.jd.com] to ipset
zfl9 commented 1 year ago 
root@ss-tproxy:/etc/ss-tproxy# diff ss-tproxy.default.conf ss-tproxy.conf
89,90c89,90
< dns_direct='223.5.5.5#53'             # 直连DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
< dns_direct6='240C::6666#53'           # 直连DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
---
> dns_direct='119.29.29.29#53'          # 直连DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
> dns_direct6='2402:4e00::#53'          # 直连DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
94,95c94,95
< dns_remote='8.8.8.8#53'               # 远程DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
< dns_remote6='2001:4860:4860::8888#53' # 远程DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
---
> dns_remote='1.0.0.1#53'               # 远程DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
> dns_remote6='2606:4700:4700::1001#53' # 远程DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器

root@ss-tproxy:/etc/ss-tproxy# dig +nocmd +noall +answer www.jd.com
www.jd.com.             3539    IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 3539 IN    CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 3539 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    3539    IN      A       117.72.226.3

root@ss-tproxy:/etc/ss-tproxy# dig +nocmd +noall +answer www.jd.com AAAA
www.jd.com.             120     IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 60 IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 60 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    120     IN      AAAA    2409:8c38:c50:603:8000::3

下面是同样使用 DNSPod 时本地不经过 ss-tproxy 代理的结果

$ dig @119.29.29.29 +nocmd +noall +answer www.jd.com | nali
www.jd.com.             1       IN      CNAME   www.jd.com.gslb.qianxun.com [京东云 CDN] .
www.jd.com.gslb.qianxun.com [京东云 CDN] . 1    IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com [京东云 CDN] .
www.jd.com.s.galileo.jcloud-cdn.com [京东云 CDN] . 1 IN CNAME   wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    1       IN      A       27.36.125.x [广东省佛山市 联通]

关于你的这个测试，我想知道你下面那个 dig 是在什么环境下执行的，在 ss-tproxy 主机（stop的情况下？），还是内网其他主机（是否网关和dns指向了ss-tproxy？），麻烦具体说下哈。

ak1ra-komj commented 1 year ago

关于你的这个测试，我想知道你下面那个 dig 是在什么环境下执行的，在 ss-tproxy 主机（stop的情况下？），还是内网其他主机（是否网关和dns指向了ss-tproxy？），麻烦具体说下哈。

上面的 root@ss-tproxy 是在 ss-tproxy 本机上, 下面的是内网其它主机, 也即我现在上网的 PC, 网关和 DNS 都没有指向 ss-tproxy

zfl9 commented 1 year ago

6-1~deb12u1-Debian <<>> @127.0.0.1 -p65353 www.jd.com

ok，在 ss-tproxy 主机（start 的情况下），执行以下命令，我看看什么情况：

# 测试直接访问 119.29.29.29
sg proxy_dns 'dig @119.29.29.29 www.jd.com'

# 测试访问 dnsmasq -> chinadns-ng -> 119
dig www.jd.com

# 测试访问 chinadns-ng -> 119
dig @127.0.0.1 -p65353 www.jd.com
zfl9 commented 1 year ago

不好意思，之前的命令打错了，是单引号哈，不是反引号

zfl9 commented 1 year ago

6-1~deb12u1-Debian <<>> @127.0.0.1 -p65353 www.jd.com

ok，在 ss-tproxy 主机（start 的情况下），执行以下命令，我看看什么情况：

# 测试直接访问 119.29.29.29
sg proxy_dns 'dig @119.29.29.29 www.jd.com'

# 测试访问 dnsmasq -> chinadns-ng -> 119
dig www.jd.com

# 测试访问 chinadns-ng -> 119
dig @127.0.0.1 -p65353 www.jd.com

看看是不是输出一样，把输出结果发出来

ak1ra-komj commented 1 year ago

6-1~deb12u1-Debian <<>> @127.0.0.1 -p65353 www.jd.com

ok，在 ss-tproxy 主机（start 的情况下），执行以下命令，我看看什么情况：

# 测试直接访问 119.29.29.29
sg proxy_dns 'dig @119.29.29.29 www.jd.com'

# 测试访问 dnsmasq -> chinadns-ng -> 119
dig www.jd.com

# 测试访问 chinadns-ng -> 119
dig @127.0.0.1 -p65353 www.jd.com
root@ss-tproxy:/etc/ss-tproxy# ss-tproxy flush-dns
root@ss-tproxy:/etc/ss-tproxy# sg proxy_dns 'dig @119.29.29.29 www.jd.com'

; <<>> DiG 9.18.16-1~deb12u1-Debian <<>> @119.29.29.29 www.jd.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19238
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: bd669a32dd140b06 (echoed)
;; QUESTION SECTION:
;www.jd.com.                    IN      A

;; ANSWER SECTION:
www.jd.com.             89      IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 29 IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 29 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    29      IN      A       27.36.125.193

;; Query time: 16 msec
;; SERVER: 119.29.29.29#53(119.29.29.29) (UDP)
;; WHEN: Sat Aug 05 00:25:58 HKT 2023
;; MSG SIZE  rcvd: 181

root@ss-tproxy:/etc/ss-tproxy# ss-tproxy flush-dns
root@ss-tproxy:/etc/ss-tproxy# dig www.jd.com

; <<>> DiG 9.18.16-1~deb12u1-Debian <<>> www.jd.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14581
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 8540fee0431fa48f (echoed)
;; QUESTION SECTION:
;www.jd.com.                    IN      A

;; ANSWER SECTION:
www.jd.com.             70      IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 10 IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 10 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    10      IN      A       27.36.125.193

;; Query time: 8 msec
;; SERVER: 1.0.0.1#53(1.0.0.1) (UDP)
;; WHEN: Sat Aug 05 00:26:17 HKT 2023
;; MSG SIZE  rcvd: 181

root@ss-tproxy:/etc/ss-tproxy# ss-tproxy flush-dns
root@ss-tproxy:/etc/ss-tproxy# dig @127.0.0.1 -p65353 www.jd.com

; <<>> DiG 9.18.16-1~deb12u1-Debian <<>> @127.0.0.1 -p65353 www.jd.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3539
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: b40c49ef2bb135fb (echoed)
;; QUESTION SECTION:
;www.jd.com.                    IN      A

;; ANSWER SECTION:
www.jd.com.             61      IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 52 IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 52 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    52      IN      A       27.36.125.193

;; Query time: 8 msec
;; SERVER: 127.0.0.1#65353(127.0.0.1) (UDP)
;; WHEN: Sat Aug 05 00:26:25 HKT 2023
;; MSG SIZE  rcvd: 181

重新执行下这几条命令, 刚刚有点混乱.

zfl9 commented 1 year ago

为什么解析时间差异这么大，经过 chinadns-ng 的是 8 ms，sg 直接访问是 16 ms

zfl9 commented 1 year ago

6-1~deb12u1-Debian <<>> @127.0.0.1 -p65353 www.jd.com

ok，在 ss-tproxy 主机（start 的情况下），执行以下命令，我看看什么情况：

# 测试直接访问 119.29.29.29
sg proxy_dns 'dig @119.29.29.29 www.jd.com'

# 测试访问 dnsmasq -> chinadns-ng -> 119
dig www.jd.com

# 测试访问 chinadns-ng -> 119
dig @127.0.0.1 -p65353 www.jd.com
root@ss-tproxy:/etc/ss-tproxy# ss-tproxy flush-dns
root@ss-tproxy:/etc/ss-tproxy# sg proxy_dns 'dig @119.29.29.29 www.jd.com'

; <<>> DiG 9.18.16-1~deb12u1-Debian <<>> @119.29.29.29 www.jd.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19238
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: bd669a32dd140b06 (echoed)
;; QUESTION SECTION:
;www.jd.com.                    IN      A

;; ANSWER SECTION:
www.jd.com.             89      IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 29 IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 29 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    29      IN      A       27.36.125.193

;; Query time: 16 msec
;; SERVER: 119.29.29.29#53(119.29.29.29) (UDP)
;; WHEN: Sat Aug 05 00:25:58 HKT 2023
;; MSG SIZE  rcvd: 181

root@ss-tproxy:/etc/ss-tproxy# ss-tproxy flush-dns
root@ss-tproxy:/etc/ss-tproxy# dig www.jd.com

; <<>> DiG 9.18.16-1~deb12u1-Debian <<>> www.jd.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14581
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 8540fee0431fa48f (echoed)
;; QUESTION SECTION:
;www.jd.com.                    IN      A

;; ANSWER SECTION:
www.jd.com.             70      IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 10 IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 10 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    10      IN      A       27.36.125.193

;; Query time: 8 msec
;; SERVER: 1.0.0.1#53(1.0.0.1) (UDP)
;; WHEN: Sat Aug 05 00:26:17 HKT 2023
;; MSG SIZE  rcvd: 181

root@ss-tproxy:/etc/ss-tproxy# ss-tproxy flush-dns
root@ss-tproxy:/etc/ss-tproxy# dig @127.0.0.1 -p65353 www.jd.com

; <<>> DiG 9.18.16-1~deb12u1-Debian <<>> @127.0.0.1 -p65353 www.jd.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3539
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: b40c49ef2bb135fb (echoed)
;; QUESTION SECTION:
;www.jd.com.                    IN      A

;; ANSWER SECTION:
www.jd.com.             61      IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 52 IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 52 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    52      IN      A       27.36.125.193

;; Query time: 8 msec
;; SERVER: 127.0.0.1#65353(127.0.0.1) (UDP)
;; WHEN: Sat Aug 05 00:26:25 HKT 2023
;; MSG SIZE  rcvd: 181

重新执行下这几条命令, 刚刚有点混乱.

不过这回，看这个输出好像3个是一样的。

zfl9 commented 1 year ago

我在本地测试，无法复现你前面的，解析结果不一致的情况。

ak1ra-komj commented 1 year ago

再执行一遍, 这次加上配置文件差异,

root@ss-tproxy:/etc/ss-tproxy# diff ss-tproxy.default.conf ss-tproxy.conf
89,90c89,90
< dns_direct='223.5.5.5#53'             # 直连DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
< dns_direct6='240C::6666#53'           # 直连DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
---
> dns_direct='119.29.29.29#53'       # 直连DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
> dns_direct6='2402:4e00::#53'          # 直连DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
94,95c94,95
< dns_remote='8.8.8.8#53'               # 远程DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
< dns_remote6='2001:4860:4860::8888#53' # 远程DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
---
> dns_remote='1.0.0.1#53'               # 远程DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
> dns_remote6='2606:4700:4700::1001#53' # 远程DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
106c106
< dnsmasq_log_enable='false'              # 记录详细日志，除非进行调试，否则不建议启用
---
> dnsmasq_log_enable='true'               # 记录详细日志，除非进行调试，否则不建议启用
118c118
< chinadns_verbose='false'                 # 记录详细日志，除非进行调试，否则不建议启用
---
> chinadns_verbose='true'                  # 记录详细日志，除非进行调试，否则不建议启用
135c135
< ipts_set_snat='false'               # 设置 ipv4 MASQUERADE(SNAT) 规则，selfonly=false 时有效，详见 README
---
> ipts_set_snat='true'                # 设置 ipv4 MASQUERADE(SNAT) 规则，selfonly=false 时有效，详见 README
280a281
>
root@ss-tproxy:/etc/ss-tproxy# ss-tproxy restart
mode:           chnroute
proxy/tcp:      [running]
proxy/udp:      [running]
dnsmasq:        [stopped]
chinadns:       [stopped]

mode:           chnroute
proxy/tcp:      [running]
proxy/udp:      [running]
dnsmasq:        [running]
chinadns:       [running]
root@ss-tproxy:/etc/ss-tproxy# sg proxy_dns 'dig @119.29.29.29 www.jd.com'

; <<>> DiG 9.18.16-1~deb12u1-Debian <<>> @119.29.29.29 www.jd.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65192
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: e3fab27aa374d52f (echoed)
;; QUESTION SECTION:
;www.jd.com.                    IN      A

;; ANSWER SECTION:
www.jd.com.             66      IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 59 IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 59 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    59      IN      A       117.72.226.3

;; Query time: 28 msec
;; SERVER: 119.29.29.29#53(119.29.29.29) (UDP)
;; WHEN: Sat Aug 05 00:30:40 HKT 2023
;; MSG SIZE  rcvd: 181

root@ss-tproxy:/etc/ss-tproxy# ss-tproxy flush-dns
root@ss-tproxy:/etc/ss-tproxy# dig www.jd.com

; <<>> DiG 9.18.16-1~deb12u1-Debian <<>> www.jd.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64662
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: a63bac22eb31d32f (echoed)
;; QUESTION SECTION:
;www.jd.com.                    IN      A

;; ANSWER SECTION:
www.jd.com.             54      IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 47 IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 47 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    47      IN      A       117.72.226.3

;; Query time: 8 msec
;; SERVER: 1.0.0.1#53(1.0.0.1) (UDP)
;; WHEN: Sat Aug 05 00:30:52 HKT 2023
;; MSG SIZE  rcvd: 181

root@ss-tproxy:/etc/ss-tproxy# ss-tproxy flush-dns
root@ss-tproxy:/etc/ss-tproxy# dig @127.0.0.1 -p65353 www.jd.com

; <<>> DiG 9.18.16-1~deb12u1-Debian <<>> @127.0.0.1 -p65353 www.jd.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60518
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 05cf11746635dcac (echoed)
;; QUESTION SECTION:
;www.jd.com.                    IN      A

;; ANSWER SECTION:
www.jd.com.             43      IN      CNAME   www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 36 IN      CNAME   www.jd.com.s.galileo.jcloud-cdn.com.
www.jd.com.s.galileo.jcloud-cdn.com. 36 IN CNAME wwwv6.jcloudimg.com.
wwwv6.jcloudimg.com.    36      IN      A       117.72.226.3

;; Query time: 16 msec
;; SERVER: 127.0.0.1#65353(127.0.0.1) (UDP)
;; WHEN: Sat Aug 05 00:31:03 HKT 2023
;; MSG SIZE  rcvd: 181
zfl9 commented 1 year ago

我看了最后两次测试，倒数第二次测试，ip都是一样的，为 27.36.125.193，最后一次测试，ip也是一样的，为117.72.226.3

ak1ra-komj commented 1 year ago

我看了最后两次测试，倒数第二次测试，ip都是一样的，为 27.36.125.193，最后一次测试，ip也是一样的，为117.72.226.3

最后两次测试的结果第一次的 27.36.125.193 是正确的, 但后一次的结果 117.72.226.3 回到了最开始的错误, 这两次配置文件是一样的

zfl9 commented 1 year ago

我只能猜测是 119.29.29.29 上游有问题，要不就是网络环境中，存在 DNS 污染？不然无法解释。

ak1ra-komj commented 1 year ago

我只能猜测是 119.29.29.29 上游有问题，要不就是网络环境中，存在 DNS 污染？不然无法解释。

最后两次测试的结果第一次的 27.36.125.193 是正确的, 但后一次的结果 117.72.226.3 回到了最开始的错误, 这两次配置文件是一样的

所以结论是 chinadns-ng 上游 DNS 的问题?

先不讨论运营商 DNS, 针对国内域名, 国内的公共 DNS 还存在 DNS 污染就很神奇了.

zfl9 commented 1 year ago

说明几点，在 ss-tproxy 主机上，如果有 dns 相关疑问，可进行如下对比测试：

zfl9 commented 1 year ago

我只能猜测是 119.29.29.29 上游有问题，要不就是网络环境中，存在 DNS 污染？不然无法解释。

最后两次测试的结果第一次的 27.36.125.193 是正确的, 但后一次的结果 117.72.226.3 回到了最开始的错误, 这两次配置文件是一样的

所以结论是 chinadns-ng 上游 DNS 的问题?

  • DNSPod (119.29.29.29), 阿里 DNS (223.5.5.5) 结果都有问题, 但是 DNSPod 出现过正确的结果
  • 114 DNS 和我后面用的运营商 DNS 针对 www.jd.com 的解析结果跟本地一致

先不讨论运营商 DNS, 针对国内域名, 国内的公共 DNS 还存在 DNS 污染就很神奇了.

最后两次测试，可以看出 直接访问119 和 经过dnsmasq/chinadns-ng访问119 并无区别，解析结果一样。

至于为什么两次测试的结果不同，一次返回正确IP，一次返回错误IP，我只能猜测是 119 这边有问题。。。

而且更奇怪的是，好像只有京东有这个问题，真是令人捉摸不透。难道京东CDN解析与119和223不兼容？

话说回来，我自己用的也是 223.5.5.5，但未发现 jd.com 相关解析异常，而且京东也正常访问，手机和PC都正常。