FakeIP(enhanced-mode: fake-ip)
假设已经通过domain进行过分流
直连
使用配置的DNS服务器进行解析
代理
- 返回FakeIP Pool中的保留地址
- 记录FakeIP与Domain映射关系
- 客户端向保留地址发起连接
- 通过FakeIP与Domain映射关系反向查询Domain
- 向代理服务器发起连接,目标地址为Domain
- 代理服务器进行二次DNS解析,连接到目标IP
RealIP
假设已经通过domain进行过分流
直连
客户端向真实IP发起连接
代理
使用域名(enhanced-mode: redir-host)
- 进行DNS查询并记录返回的IP和域名关系
- 此时如果遇到CDN域名的情况,需要额外处理来保证映射的准确性,比如DNS解析结果为1.1.1.1的Cloudflare AnycastIP,此IP对应多个域名,IP与域名为一对多的关系
- 客户端向IP发起连接,通过IP反查域名
- 向代理服务器发起连接,目标地址为Domain
- 代理服务器进行二次DNS解析,连接到目标IP
使用IP(enhanced-mode: normal)
- 进行DNS查询
- 客户端向真实IP发起连接
- 向代理服务器发起连接,目标地址为IP
规则匹配
- 阶段一:DNS解析时期的规则匹配,对不同的域名使用不同的DNS服务器进行解析
- 阶段二:客户端发起连接,代理软件收到连接后,选择出站的规则匹配
在FakeIP和RealIP(域名)模式下,两个阶段互相有关联,阶段二需要使用阶段一的域名来覆盖连接的目标地址(override-destination),以此实现准确的DNS解析。
在RealIP(IP)的模式下,两个阶段完全分离,DNS解析的结果是最终连接的目标地址
嗅探
嗅探可以通过观测一个已经打开的连接,获取这个连接中的域名。此时获取的域名可以选择只用过规则匹配,或覆盖连接的目标地址(override-destination)
理想情况下,配置正确时
- FakeIP: 不需要启用嗅探,因为DNS解析是保留了完整的域名,不需要在连接发起时进行嗅探,带来了额外的性能开销,而且容易引发错误。
- 有些时候,嗅探出来的域名并不是连接的最终域名,比如Mijia Cloud,有些米家设备的SNI是
Mijia Cloud很明显这不是一个域名,如果启用了override-destination,米家设备有可能连不上网络
- 有些时候,嗅探出来的域名并不是连接的最终域名,比如Mijia Cloud,有些米家设备的SNI是
- redir-host: 需要开启嗅探,为了处理IP和域名一对多的情况,如果外开启,你可能会遇到网站SSL错误,域名和证书不一致的错误
- normal: 建议开启,否则不能使用基于IP的域名匹配规则,对于特定网站的分流将失效
ECH
ECH(Encrypted Client Hello)可以加密连接中的SNI信息,对于网络防火墙来说,无法获取连接的域名,无法进行SNI阻断。对于代理来说,无法通过嗅探获取域名,无法进行指定域名的分流(仅normal)模式下。
总结
我建议的配置
FakeIP模式
dns:
enable: true
cache-algorithm: arc
respect-rules: true
prefer-h3: false
use-system-hosts: true
ipv6: false
listen: "[::]:1053"
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- geosite:connectivity-check
- geosite:private
- geosite:cn
use-hosts: true
rebind: false
default-nameserver:
- system
proxy-server-nameserver:
- system
nameserver:
- system
sniffer:
enable: false
force-dns-mapping: false
parse-pure-ip: false
override-destination: false
fake-ip-filter:connectivity-check中包含了连接性检查的域名。系统会向这些域名发送ICMP Ping,代理软件不能代理ICMP协议,所以此处返回realip,防止设备觉得自己断网了
# ArchLinux
ping.archlinux.org
# Apple
captive.apple.com
# Android
connectivitycheck.gstatic.com
# Cloudflare
cp.cloudflare.com
# Debian
network-test.debian.org
# Firefox
detectportal.firefox.com
# Honor
full:connectivitycheck.platform.hihonorcloud.com
# Huawei
full:connectivitycheck.platform.hicloud.com
# KDE
networkcheck.kde.org
# MIUI
full:connect.rom.miui.com
# Windows
msftconnecttest.com
msftncsi.com
rebind: false:如果你需要访问局域网内的内网网站,设置为false,否则设置为true,启用这一项设置,代理软件会认为,如果DNS解析过程中收到了内网IP,则此次DNS解析被污染,会抛弃DNS解析结果。nameserver:所有fake-ip-filter中的网站会使用nameserver进行解析,此次没有需要被代理的网站,所以不需要配置任何一个代理的DNS服务器
Normal模式
CodeBlock Loading...
enhanced-mode: normal:不进行IP和域名的映射nameserver-policy:- 此时需要手动配完整的DNS分流规则
- 对于特定网站的分流为了保证DNS出口和代理的出口一致,建议使用单独的DNS服务器,并配置
#AI用于指定DNS的出站服务器,这样,当AI策略组切换到SG的时候,DNS解析也将会在SG进行 - 不需要ECS
force-dns-mapping: false:取消IP和域名映射parse-pure-ip: true:嗅探纯IP连接,只对没有获取域名的连接进行嗅探override-destination: false:嗅探的结果只用于规则匹配,不用于实际连接,发送到代理服务器的是IP不是域名
redir-host不建议使用
分流规则
CodeBlock Loading...
proxy-groups: name: DNS:指定DNS解析的出口proxy-groups: name: FALLBACK:故障转移,多个阶段按照优先级自动选择
其他
CodeBlock Loading...
geodata-mode: false:能显著提升软件启动时间,使用mmdb格式的规则集文件,不使用dat格式,dat启动时加载很慢
这么多规则匹配并不会耗费太多时间,平均时间在200微秒左右,0.2毫秒
