[Bug] <代理的域名解析应考虑TTL>
kwokpia opened this issue · 2 comments
kwokpia commented
先决条件
- 我了解这里是开源版 Clash.Rev 核心仓库
- 我要提交 Clash.Rev 核心的问题,并非 Clash.Meta / OpenClash / ClashX / Clash For Windows 或其他任何衍生版本的问题
- 我使用的是本仓库最新版本的 Clash.Rev 内核
- 我已经在 Issue Tracker 中找过我要提出的 bug,并且没有找到相关问题
- 我已经仔细阅读 官方 Wiki 并无法自行解决问题
版本
clash.rev-linux-amd64-cgo-v1.0.2
适用的作业系统
Linux
适用的硬件架构
amd64
配置文件
proxy-providers:
airportA:
type: http
url: https://xxx
interval: 3600
path: ./airportA.yaml
health-check:
enable: true
interval: 36000
url: http://www.gstatic.com/generate_204
dns:
enable: true
listen: 0.0.0.0:53
ipv6: true
default-nameserver:
- 192.168.1.1
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- '+.lan'
- '+.local'
- '+.time.google.com'
- '+.ntp.ubuntu.com'
- '+.ntp.org'
- '+.time.apple.com'
nameserver:
- 192.168.1.1
fallback:
- dot.pub
fallback-filter:
geoip: false
ipcidr:
- 240.0.0.0/4
- 0.0.0.0/32
- 127.0.0.1/32
airportA.yaml
proxies:
- name: 香港-广东专线 DP 1
type: trojan
server: example.com
port: xxx
password: xxx
udp: true
sni: xxx
#假设代理的域名为example.com,
日志输出
curl --socks5 localhost:7890 twitter.com
DEBU[2023-11-17T20:37:08.55655162+08:00] [Rule] use default rules
DEBU[2023-11-17T20:37:08.556841049+08:00] [DNS] resolve example.com from udp://192.168.1.1:53
DEBU[2023-11-17T20:37:08.556952185+08:00] [DNS] resolve example.com from udp://192.168.1.1:53
DEBU[2023-11-17T20:37:08.564788831+08:00] [DNS] example.com --> [x.x.x.x] A from udp://192.168.1.1:53
DEBU[2023-11-17T20:37:08.568433889+08:00] [DNS] example.com --> [] AAAA from udp://192.168.1.1:53
DEBU[2023-11-17T20:37:08.568550605+08:00] [DNS] resolve example.com from udp://dot.pub:53
DEBU[2023-11-17T20:37:08.56865657+08:00] [DNS] resolve dot.pub from udp://192.168.1.1:53
DEBU[2023-11-17T20:37:08.577520333+08:00] [DNS] dot.pub --> [1.12.34.56] A from udp://192.168.1.1:53
INFO[2023-11-17T20:37:08.712748267+08:00] [TCP] 127.0.0.1:34738 --> twitter.com:80 match RuleSet(proxy-domain) using common-S[🇭🇰 香港-广东专线 DP 1]
curl --socks5 localhost:7890 facebook.com
DEBU[2023-11-17T20:37:30.743053713+08:00] [Rule] use default rules
DEBU[2023-11-17T20:37:30.743463835+08:00] [DNS] resolve example.com from udp://192.168.1.1:53
DEBU[2023-11-17T20:37:30.744350285+08:00] [DNS] example.com --> [] AAAA from udp://192.168.1.1:53
DEBU[2023-11-17T20:37:30.744432303+08:00] [DNS] resolve example.com from udp://dot.pub:53
INFO[2023-11-17T20:37:31.007169327+08:00] [TCP] 127.0.0.1:48846 --> facebook.com:80 match RuleSet(proxy-domain) using common-S[🇭🇰 香港-广东专线 DP 1]
问题描述
每建立一个连接都会重新解析代理的域名,即使代理的域名的TTl还没到期.
如日志所示,连续的两次建立连接都去解析了example.com的DNS.
复现步骤
No response
MerlinKodo commented
你好,Clash内部使用了In memory cache来缓存DNS解析结果,具体的缓存功能相关代码在
https://github.com/MerlinKodo/clash-rev/blob/dev/common/cache/lrucache.go
https://github.com/MerlinKodo/clash-rev/blob/dev/dns/resolver.go
更具体的来说,resolver.go
文件的ExchangeContext
函数中实现了相关Cache查询功能
此外通过添加额外的debug日志可以看到如下记录:
time="2023-11-18T01:31:36.2150395-08:00" level=debug msg="[Rule] use default rules"
Time: 2023-11-18 01:31:36 Debug Query: ;twitter.com. IN A
Time: 2023-11-18 01:31:36 Not hit cache for: ;twitter.com. IN A
Time: 2023-11-18 01:31:36 Debug Query: ;twitter.com. IN AAAA
Time: 2023-11-18 01:31:36 Not hit cache for: ;twitter.com. IN AAAA
time="2023-11-18T01:31:36.2155446-08:00" level=debug msg="[DNS] resolve twitter.com from udp://x.x.x.x:53"
time="2023-11-18T01:31:36.2160711-08:00" level=debug msg="[DNS] resolve twitter.com from udp://x.x.x.x:53"
time="2023-11-18T01:31:36.2196092-08:00" level=debug msg="[DNS] twitter.com --> [x.x.x.x] A from udp://x.x.x.x:53"
time="2023-11-18T01:31:36.2229242-08:00" level=debug msg="[DNS] twitter.com --> [] AAAA from udp://x.x.x.x:53"
time="2023-11-18T01:31:36.2229242-08:00" level=debug msg="[DNS] twitter.com --> x.x.x.x"
time="2023-11-18T01:31:37.2951361-08:00" level=info msg="[TCP] --> twitter.com:443 match Match using PROXY"
time="2023-11-18T01:32:27.4310225-08:00" level=debug msg="[Rule] use default rules"
Time: 2023-11-18 01:32:27 Debug Query: ;www.twitter.com. IN A
Time: 2023-11-18 01:32:27 Hit cache for: ;www.twitter.com. IN A
Time: 2023-11-18 01:32:27 Debug Query: ;www.twitter.com. IN AAAA
Time: 2023-11-18 01:32:27 Hit cache for: ;www.twitter.com. IN AAAA
time="2023-11-18T01:32:27.4315287-08:00" level=debug msg="[DNS] www.twitter.com --> x.x.x.x"
time="2023-11-18T01:32:28.4678944-08:00" level=info msg="[TCP] --> www.twitter.com:443 match Match using PROXY"
可见第二次请求中使用了缓存结果,而没有发起新的DNS请求
kwokpia commented
你好,Clash内部使用了In memory cache来缓存DNS解析结果,具体的缓存功能相关代码在
dev
/common/cache/lrucache.godev
/dns/resolver.go更具体的来说,
resolver.go
文件的ExchangeContext
函数中实现了相关Cache查询功能此外通过添加额外的debug日志可以看到如下记录:
time="2023-11-18T01:31:36.2150395-08:00" level=debug msg="[Rule] use default rules" Time: 2023-11-18 01:31:36 Debug Query: ;twitter.com. IN A Time: 2023-11-18 01:31:36 Not hit cache for: ;twitter.com. IN A Time: 2023-11-18 01:31:36 Debug Query: ;twitter.com. IN AAAA Time: 2023-11-18 01:31:36 Not hit cache for: ;twitter.com. IN AAAA time="2023-11-18T01:31:36.2155446-08:00" level=debug msg="[DNS] resolve twitter.com from udp://x.x.x.x:53" time="2023-11-18T01:31:36.2160711-08:00" level=debug msg="[DNS] resolve twitter.com from udp://x.x.x.x:53" time="2023-11-18T01:31:36.2196092-08:00" level=debug msg="[DNS] twitter.com --> [x.x.x.x] A from udp://x.x.x.x:53" time="2023-11-18T01:31:36.2229242-08:00" level=debug msg="[DNS] twitter.com --> [] AAAA from udp://x.x.x.x:53" time="2023-11-18T01:31:36.2229242-08:00" level=debug msg="[DNS] twitter.com --> x.x.x.x" time="2023-11-18T01:31:37.2951361-08:00" level=info msg="[TCP] --> twitter.com:443 match Match using PROXY" time="2023-11-18T01:32:27.4310225-08:00" level=debug msg="[Rule] use default rules" Time: 2023-11-18 01:32:27 Debug Query: ;www.twitter.com. IN A Time: 2023-11-18 01:32:27 Hit cache for: ;www.twitter.com. IN A Time: 2023-11-18 01:32:27 Debug Query: ;www.twitter.com. IN AAAA Time: 2023-11-18 01:32:27 Hit cache for: ;www.twitter.com. IN AAAA time="2023-11-18T01:32:27.4315287-08:00" level=debug msg="[DNS] www.twitter.com --> x.x.x.x" time="2023-11-18T01:32:28.4678944-08:00" level=info msg="[TCP] --> www.twitter.com:443 match Match using PROXY"
可见第二次请求中使用了缓存结果,而没有发起新的DNS请求
感谢回复