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毫秒
