关于mihomo配置文件dns泄漏的问题,Gemini说是mihomo的bug。求大佬们指导!

柴柴不是柴✨ 2025-07-19 01:01 1

此配置,我已明确查明dns泄漏的原因。这里仅作为小白求学探讨。求大佬们多多指点!!!






配置如下,有dns泄漏,原因已查明

# **=============================== 代理配置 ===============================**
# 机场/代理提供者设置,用于从不同的来源提供代理节点
dy: &dy
type: http
udp: true
interval: 86400
proxy: DIRECTLY
lazy: true
health-check:
enable: true
url: https://cp.cloudflare.com/generate_204
interval: 600
timeout: 5 # 秒
lazy: true
expected-status: "204"
method: HEAD
# ⚠️ smux 多路复用:部分机场不支持,如连接失败请注释本段
# 稳定性出现问题,可以尝试切换为 smux4 或禁用 padding。
smux: # smux(连接复用,提升多路复用效率,减少握手)
enabled: true # 开启 smux 多路复用
padding: true # 增加随机数据,防探测(推荐开)
protocol: smux # 或 smux4

u: &u # **所有订阅组引用**
use:
- 1.p1
- 2.p2
- 3.p3
- 4.p4

u_s: &u_s # **主用订阅组引用**
use:
- 2.p2
- 3.p3

# **各种代理提供者(机场)的订阅配置**
proxy-providers:
1.p1:
url: ""
path: ./proxy_provider/p1.yaml
lazy: true
<<: *dy
override:
additional-prefix: "p1 »"
health-check:
enable: false

2.p2:
url: ""
path: ./proxy_provider/p2.yaml
<<: *dy
override:
additional-prefix: "p2 »"

3.p3:
url: ""
path: ./proxy_provider/p3.yaml
lazy: true
<<: *dy
override:
additional-prefix: "p3 »"
health-check:
enable: false

4.p4:
url: ""
path: ./proxy_provider/p4.yaml
<<: *dy
override:
additional-prefix: "p4 »"

# **=============================== 节点信息 ===============================**
proxies:
- { name: DIRECTLY, type: direct, udp: true }

# 家宽来源 :https://linux.do/t/topic/744482

# **=============================== DNS 配置 ===============================**
# DNS 解析配置,决定了域名解析方式和缓存策略
dns:
enable: true # 启用 DNS 功能
ipv6: true
listen: 0.0.0.0:1053 # 监听地址和端口
prefer-h3: false # 如果DNS服务器支持DoH3会优先使用h3,提升性能
respect-rules: true # 让 DNS 解析遵循 Clash 的路由规则
cache-algorithm: arc # 使用性能更优的 ARC 缓存算法
cache-size: 2048 # 限制缓存大小,避免占用过多内存

use-hosts: false # 使用hosts
use-system-hosts: false # 使用系统hosts

# 启用 Fake-IP 模式,这是强制劫持所有 DNS 请求的关键。
enhanced-mode: fake-ip # 设置增强模式为 fake-ip 模式,提高解析速度和连接性能
fake-ip-range: 198.18.0.1/16 # fake-ip 地址范围
# Fake-IP 过滤器:确保国内域名不被 Fake-IP 转换。
fake-ip-filter-mode: blacklist
fake-ip-filter:
- "rule-set:private_domain,cn_domain"
- "geosite:connectivity-check"
- "geosite:private"
- "rule-set:fake_ip_filter_DustinWin"
# - "rule-set:fake_ip_filter_juewuy"

default-nameserver:
- 1.1.1.1 # Cloudflare Public DNS (UDP)
- 8.8.8.8 # Google Public DNS (UDP)
# 为配合rules中的IP-CIDR注释掉,防止dns泄露(启用就泄露)
# - 223.5.5.5 # 阿里(国内)
# - 119.29.29.29 # 腾讯(国内)
# - system # 系统 DNS (保留以防万一)

#`nameserver-policy` 精准分流与严格兜底。**
# 确保国内域名走国内 DNS,境外域名走境外 DNS。这是解决问题的关键。
# 这是 Clash 进行主要 DNS 查询时使用的服务器列表。
nameserver: # 默认 DNS,供所有请求使用,支持 DoH3 的在前面
- https://1.1.1.1/dns-query # Cloudflare(支持 H3)
- https://dns.google/dns-query # Google(支持 H3)
- 1.1.1.1 # Cloudflare Public DNS (UDP)
- 8.8.8.8 # Google Public DNS (UDP)
# 为配合rules中的IP-CIDR注释掉,防止dns泄露(启用就泄露)
# - https://dns.alidns.com/dns-query # 阿里(国内稳定)
# - https://doh.pub/dns-query # 腾讯 (境内,DoH,可作为备选)

nameserver-policy:
"DOMAIN-SUFFIX,browserleaks.org": # 新增:强制 browserleaks.org 走国外 DNS
- https://1.1.1.1/dns-query
- https://dns.google/dns-query
- 1.1.1.1
- 8.8.8.8
"geosite:cn,private": # 国内域名和私有域名强制走国内 DNS
- https://223.5.5.5/dns-query # 阿里
- https://doh.pub/dns-query # 腾讯
- 223.5.5.5 # 阿里 UDP
- 119.29.29.29 # 腾讯 UDP
"geo:cn": # 也可以用 geo:cn 匹配 IP
- https://223.5.5.5/dns-query
- https://doh.pub/dns-query
- 223.5.5.5 # 阿里 UDP
- 119.29.29.29 # 腾讯 UDP
"geosite:gfw": # 新增:GFW 列表域名强制走国外 DNS
- https://1.1.1.1/dns-query
- https://dns.google/dns-query
- 1.1.1.1
- 8.8.8.8
"geosite:geolocation-!cn": # 新增:非中国大陆域名强制走国外 DNS
- https://1.1.1.1/dns-query
- https://dns.google/dns-query
- 1.1.1.1
- 8.8.8.8
"full-nameserver": # 新增:最终兜底,所有未匹配的域名查询强制走国外 DNS
- https://1.1.1.1/dns-query
- https://dns.google/dns-query
- 1.1.1.1
- 8.8.8.8

# 当 `nameserver` 中的 DNS 服务器解析失败时,Clash 会尝试这里的 DNS。
fallback:
- 1.1.1.1 # Cloudflare DNS备用
- 8.8.8.8 # Google DNS备用
# - 9.9.9.9 # Quad9 (备选,更注重隐私和安全性)

# `proxy-server-nameserver`: 用于代理服务器自身的 DNS 解析,仅包含国外 DNS。
proxy-server-nameserver: # 当请求通过代理(即国外站)时使用
- https://1.1.1.1/dns-query # Cloudflare,DoH3
- https://dns.google/dns-query # Google,DoH3
- 1.1.1.1
- 8.8.8.8

# **控制面板**
external-controller: 127.0.0.1:9090
secret: "123465."
external-ui: "./ui"
external-ui-url: "https://github.com/Zephyruso/zashboard/releases/latest/download/dist.zip"

# **=============================== 全局设置 ===============================**
# 影响全局网络和系统的配置
# 设置代理监听的端口、系统参数等
# 控制代理如何与系统交互
port: 7890
socks-port: 7891 # SOCKS5 代理端口
redir-port: 7892 # 透明代理端口,用于 Linux 和 MacOS
mixed-port: 7893 # HTTP(S) 和 SOCKS 代理混合端口
tproxy-port: 7894
allow-lan: true # 允许局域网连接
mode: rule
bind-address: "*" # 绑定 IP 地址,仅作用于 allow-lan 为 true,'*'表示所有地址
ipv6: true
unified-delay: true # 更换延迟计算方式,去除握手等额外延迟
tcp-concurrent: true # 启用 TCP 并发连接。这允许 Clash 同时建立多个 TCP 连接,可以提高网络性能和连接速度
log-level: debug # 查东西时改成info
find-process-mode: "strict" # 设置进程查找模式为严格模式,Clash 会更精确地识别和匹配网络流量来源的进程
global-client-fingerprint: chrome # 设置全局客户端指纹为 Chrome,使 Clash 在建立连接时模拟 Chrome 浏览器的 TLS 指纹,增强隐私性和绕过某些网站的指纹检测
keep-alive-idle: 600
keep-alive-interval: 15
disable-keep-alive: false

profile:
store-selected: true # 记忆选择
store-fake-ip: true

# **=============================== 流量嗅探配置 ===============================**
# 启用流量嗅探功能,用于监控和分析网络流量
sniffer:
enable: true
sniff:
HTTP:
ports: [80, 8080-8880]
override-destination: true
TLS:
ports: [443, 8443]
QUIC:
ports: [443, 8443]
force-domain:
- "+.v2ex.com"
skip-domain:
- "+.baidu.com"
- "+.bilibili.com"

# **=============================== TUN 配置 ===============================**
# 配置 TUN 模式,适用于透明代理和高效流量转发
tun:
enable: true
stack: mixed # system/gvisor/mixed
auto-route: true
auto-redirect: true
auto-detect-interface: true
strict-route: true # 避免冗余路由污染系统表
dns-hijack:
- any:53
- tcp://any:53
mtu: 1500 # 减少 MTU 问题,如网页无法打开、测速慢
gso: true # 启用通用分段卸载(提升性能)
gso-max-size: 65536
udp-timeout: 300 # UDP 会话保持时间

# **=============================== GEO 数据库配置 ===============================**
# 该配置用于加载地理位置信息数据库,包括 IP 和域名的地理位置数据
# 在不同的规则配置中,可以使用地理信息进行更精确的流量路由

# GEO 数据库模式配置,启用该功能以获取和使用地理位置信息
geodata-mode: true

# GEO 数据库加载模式,选择合适的内存占用策略
# 'memconservative' 适用于较低内存占用,保证系统性能
geodata-loader: memconservative

# 是否自动更新 GEO 数据库,默认每48小时更新一次
geo-auto-update: true
# GEO 数据库更新间隔时间,单位为小时
geo-update-interval: 48

# GEO 数据库文件下载地址配置,提供各类 GEO 数据文件的 URL,确保实时更新
geox-url:
geoip: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geoip.dat"
geosite: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat"
mmdb: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geoip.metadb"

# **=============================== GEO 数据库说明 ===============================**
# **GEO 数据库提供 IP 和域名的地理位置信息,用于路由决策和策略执行**
# **比如根据用户所在地区来决定代理节点的选择或域名的处理方式**
# **使用此功能时,需确保你的配置已经加载最新的 GEO 数据,避免误判或性能下降**

# **'geoip' 是基于 IP 地址的地理信息,常用于判断源 IP 的地域**
# **'geosite' 是基于域名的地理信息,适合对特定域名进行地域分类**
# **'mmdb' 文件则包含了更为详细的 IP 地理信息,提升定位精度,通常用于更高阶的路由配置**
# **============================================================================**

# **=============================== 代理组设置 ===============================**
# 代理组用于管理不同代理的分类和调度策略
# 注意锚点必须放在引用的上方,可以集中把锚点全部放yaml的顶部。
# 整体调用模版
pg: &pg
type: select
proxies:
- Proxy
- 香港故转
- 美国故转
- 新加坡故转
- 香港均衡加速
- 美国均衡加速
- 新加坡均衡加速
- 香港自动
- 美国自动
- 新加坡自动
- 自动选择
- 香港节点
- 美国节点
- 日本节点
- 全部节点
- DIRECTLY

rtt-balance-template: &rtt-lb # 均衡加速
type: url-test # load-balance
<<: *u_s
lazy: false
interval: 180
tolerance: 15

# 代理组
proxy-groups:
- name: Proxy
type: select
proxies:
- 香港故转
- 美国故转
- 新加坡故转
- 香港均衡加速
- 美国均衡加速
- 新加坡均衡加速
- 香港自动
- 美国自动
- 新加坡自动
- 自动选择
- 香港节点
- 美国节点
- 日本节点
- 全部节点
icon: "https://raw.githubusercontent.com/Mithcell-Ma/icon/refs/heads/main/Manual_Test_Log.png"

# AI 主策略组:手动选择入口
- name: AI
type: select
proxies:
- AI_稳定节点 # 优先推荐:使用经过筛选的稳定节点,减少IP波动
- AI_自动优选 # 备用选项:自动寻找最优美新节点,确保可用性
icon: "https://github.com/DustinWin/ruleset_geodata/releases/download/icons/ai.png"

# --- AI_稳定节点:针对 AI 服务优化,优先保持IP稳定 ---
# 类型:fallback (故障转移),在当前节点失效时自动切换到下一个可用节点
# 节点来源:通过 *u_s 引用所有订阅的节点,并使用 filter 精确筛选(指定节点)
- name: AI_稳定节点
type: fallback # 策略类型:故障转移,优先使用列表中的第一个可用节点
<<: *u_s # <--- 引用主用代理组提供者的节点集合
url: https://cp.cloudflare.com/generate_204 # 节点健康检查URL
interval: 7200 # 测速间隔:2 小时 (7200 秒),降低节点切换频率,有助于保持IP稳定性
strategy: consistent-hashing # 一致性哈希,减少IP波动。
max-failed-times: 1 # 失效阈值:节点测试失败 1 次即认为失效,切换到下一个节点
tolerance: 100 # RTT 容忍度:减少因网络微小波动导致的频繁切换
lazy: true # 懒惰测速:节点仅在需要时进行测速,减少资源消耗
# 节点筛选器,使用 filter 精确筛选出您想要的 AI 节点,包括其前缀
# 格式:使用您客户端中显示的完整节点名称,包括 "p2 »" 前缀
# 注意:filter 中的名称要与 additional-prefix: "p2 »" 生效后的显示名称完全匹配
# **务必替换为从客户端复制的精确名称,多个用 | 分隔**
filter: "s_500G »🇺🇸 美国-03|s_500G »🇸🇬 狮城-03|s_500G »🇺🇸 美国-01"
icon: "https://testingcf.jsdelivr.net/gh/aihdde/Rules@master/icon/ai.png"

# --- AI_自动优选:AI 稳定节点失效时的备用方案,追求最佳速度 ---
# 类型:url-test (自动测速),自动选择延迟最低且可用的节点
# 节点来源:通过 *u_s 引用所有订阅的节点,并使用 filter 筛选出美新区域节点
- name: AI_自动优选
type: url-test # 策略类型:自动测速选择最佳节点
<<: *u_s # <--- 引用主用代理组提供者的节点集合
url: https://cp.cloudflare.com/generate_204 # 节点健康检查URL (或更针对 AI 服务的测速URL)
interval: 3600 # 测速间隔延长至 1 小时 (3600 秒),平衡速度与资源消耗,降低切换频率
tolerance: 50 # RTT 容忍度:适度允许延迟波动,避免过于频繁的切换
lazy: false # 积极测速:保持对所有节点活跃测速,确保始终选择最优
# 节点筛选器:仅筛选出美国和新加坡地区的节点 (大小写不敏感)
# filter: "(?i)(🇺🇸|美国|美國|US|united\\s?states|america|usa|洛杉矶|达拉斯|New\\s?York|西雅图|🇸🇬|新加坡|狮城|SG|Singapore)" # 仅筛选美新节点
# preferred 参数:指定希望优先选择的节点列表
# 如果您发现某些节点,虽然测速不总是第一,但实际体验更佳,可以将其名称加入
# preferred:
# - '机场自定义前缀 »指定节点名称' # 假设这是您认为在自动优选中也较稳定的节点
# - 's_500 »🇺🇸 美国-01'
# 请替换为实际的节点名称,并根据需要添加更多
icon: "https://raw.githubusercontent.com/Mithcell-Ma/icon/refs/heads/main/ai_backup.png"

# 🧪 高阶智能均衡测速组(支持 RTT+轮询,Android / macOS 均兼容)
- {
name: 香港均衡加速,
<<: *rtt-lb,
filter: "(?i)(香港|hk|🇭🇰|hong\\s?kong)",
icon: "https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/refs/heads/release/icon/color/available.png",
}
- {
name: 美国均衡加速,
<<: *rtt-lb,
filter: "(?i)(🇺🇸|美国|美國|US|united\\s?states|america|usa|洛杉矶|达拉斯|New\\s?York|西雅图)",
icon: "https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/refs/heads/release/icon/color/available.png",
}
- {
name: 新加坡均衡加速,
<<: *rtt-lb,
filter: "(?i)(🇸🇬|新加坡|狮城|SG|Singapore)",
icon: "https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/refs/heads/release/icon/color/available.png",
}

# 🛡️ 国家智能容灾 fallback(用于断流/封锁自动切)
- {
name: 香港故转,
type: select,
<<: *u_s,
filter: "(?i)(香港|hk|🇭🇰|hong\\s?kong)",
icon: "https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/refs/heads/master/icon/color/asn.png",
}
- {
name: 美国故转,
type: select,
<<: *u_s,
filter: "(?i)(🇺🇸|美国|美國|US|united\\s?states|america|usa|洛杉矶|达拉斯|New\\s?York|西雅图)",
icon: "https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/refs/heads/master/icon/color/asn.png",
}
- {
name: 新加坡故转,
type: select,
<<: *u_s,
filter: "(?i)(🇸🇬|新加坡|狮城|SG|Singapore)",
icon: "https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/refs/heads/master/icon/color/asn.png",
}

# 🧠 智能自动测速(可关闭 lazy 或自定义测速 URL)
- {
name: 香港自动,
type: url-test,
<<: *u_s,
include-all: false,
tolerance: 100,
interval: 600,
lazy: true,
filter: "(?i)(香港|hk|🇭🇰|hong\\s?kong)",
icon: "https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/refs/heads/release/icon/color/auto.png",
}
- {
name: 美国自动,
type: url-test,
<<: *u_s,
include-all: false,
tolerance: 100,
interval: 600,
lazy: true,
filter: "(?i)(🇺🇸|美国|US|united\\s?states|america|usa|洛杉矶|达拉斯|New\\s?York|西雅图)",
icon: "https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/refs/heads/release/icon/color/auto.png",
}
- {
name: 新加坡自动,
type: url-test,
<<: *u_s,
include-all: false,
tolerance: 100,
interval: 600,
lazy: true,
filter: "(?i)(🇸🇬|新加坡|狮城|SG|Singapore)",
icon: "https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/refs/heads/release/icon/color/auto.png",
}

- name: 自动选择
type: url-test
<<: *u_s
url: https://cp.cloudflare.com/generate_204
include-all: false
tolerance: 50
interval: 900 #安卓可用1800,也就是半小时
lazy: false
health-check:
enable: true
interval: 900
url: https://cp.cloudflare.com/generate_204
method: HEAD
timeout: 5
expected-status: "204"
filter: "(?i)^((?!(DIRECTLY|DIRECT|Proxy|Traffic|Expire|Expired|过期|剩余|流量|官网|超时|timeout|失效|Invalid|Test|测速|本地|Local)).)*$"
icon: "https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/refs/heads/master/icon/color/urltest.png"

# 📺 媒体平台
- {
name: TikTok,
hidden: true,
type: select,
proxies:
[
美国故转,
美国均衡加速,
新加坡故转,
新加坡均衡加速,
美国节点,
新加坡节点,
日本节点,
],
icon: "https://testingcf.jsdelivr.net/gh/Koolson/Qure@master/IconSet/Color/TikTok.png",
}
- {
name: YouTube,
hidden: true,
type: select,
<<: *pg,
icon: "https://testingcf.jsdelivr.net/gh/Koolson/Qure@master/IconSet/Color/YouTube.png",
}

- name: Netflix
hidden: true
type: url-test
<<: *u_s # 引用主用订阅组的节点,包含了所有机场节点
url: https://cp.cloudflare.com/generate_204
interval: 300
tolerance: 50
lazy: false
# filter: "(?i)(🇺🇸|美国|新加坡|英国|日本|香港|台湾|韩国)" # <-- **注释掉或删除此行**
filter: "(?i)^((?!(DIRECTLY|DIRECT|Proxy|Traffic|Expire|Expired|过期|剩余|流量|官网|超时|timeout|失效|Invalid|Test|测速|本地|Local)).)*$"
icon: "https://testingcf.jsdelivr.net/gh/Koolson/Qure@master/IconSet/Color/Netflix.png"

- name: Disney+
hidden: true
type: url-test
<<: *u_s
url: https://www.disneyplus.com/robots.txt
interval: 300
tolerance: 50
lazy: false
# filter: "(?i)(🇺🇸|美国|新加坡|英国|加拿大|澳大利亚)" # <-- **注释掉或删除此行**
filter: "(?i)^((?!(DIRECTLY|DIRECT|Proxy|Traffic|Expire|Expired|过期|剩余|流量|官网|超时|timeout|失效|Invalid|Test|测速|本地|Local)).)*$"
icon: "https://testingcf.jsdelivr.net/gh/Koolson/Qure@master/IconSet/Color/Disney+.png"

- {
name: Speedtest,
hidden: true,
type: select,
proxies: [DIRECTLY, Proxy],
icon: "https://testingcf.jsdelivr.net/gh/Koolson/Qure@master/IconSet/Color/Speedtest.png",
}
- {
name: OneDrive,
hidden: true,
type: select,
proxies: [DIRECTLY, Proxy],
icon: "https://testingcf.jsdelivr.net/gh/Koolson/Qure@master/IconSet/Color/OneDrive.png",
}
- {
name: Trackerslist,
hidden: true,
type: select,
proxies: [DIRECTLY, Proxy],
icon: "https://github.com/DustinWin/ruleset_geodata/releases/download/icons/trackerslist.png",
}

# 🌍 区域节点直选(供 UI 手动切换)
- {
name: 香港节点,
type: select,
<<: *u,
skip-cert-verify: true,
include-all: true,
filter: "(?i)(香港|hk|🇭🇰|hong\\s?kong)",
icon: "https://testingcf.jsdelivr.net/gh/Koolson/Qure@master/IconSet/Color/Hong_Kong.png",
}
- {
name: 美国节点,
type: select,
<<: *u,
skip-cert-verify: true,
include-all: true,
filter: "(?i)(🇺🇸|美国|US|united\\s?states|america|usa|洛杉矶|达拉斯|New\\s?York|西雅图)",
icon: "https://testingcf.jsdelivr.net/gh/Koolson/Qure@master/IconSet/Color/United_States.png",
}
- {
name: 新加坡节点,
type: select,
<<: *u,
skip-cert-verify: true,
include-all: true,
filter: "(?i)(🇸🇬|新加坡|狮城|SG|Singapore)",
icon: "https://testingcf.jsdelivr.net/gh/Koolson/Qure@master/IconSet/Color/Singapore.png",
}
- {
name: 日本节点,
type: select,
<<: *u,
skip-cert-verify: true,
include-all: true,
filter: "(?i)(🇯🇵|日本|東京|东京|JP|japan|tokyo|osaka)",
icon: "https://testingcf.jsdelivr.net/gh/Koolson/Qure@master/IconSet/Color/Japan.png",
}

# - { name: 直连域名, type: select, proxies: [DIRECTLY, Proxy], icon: "https://github.com/DustinWin/ruleset_geodata/releases/download/icons/cn.png" }
- {
name: 全部节点,
type: select,
<<: *u,
icon: "https://testingcf.jsdelivr.net/gh/Koolson/Qure@master/IconSet/Color/World_Map.png",
include-all: true,
filter: "(?i)^((?!(DIRECTLY|DIRECT|Proxy|Traffic|Expire|Expired|过期|剩余|流量|官网|超时|timeout|失效|Invalid|Test|测速|本地|Local)).)*$",
}
- {
name: 漏网之鱼,
type: select,
<<: *pg,
icon: "https://testingcf.jsdelivr.net/gh/aihdde/Rules@master/icon/fish.png",
}

# **=============================== 规则设置 ===============================**
# 用于配置规则引擎,决定哪些流量走哪些代理
rules:
# --- 1. 拒绝/阻止类规则 (最高优先级,直接拦截) ---
# 这些规则不涉及 DNS 解析,直接拒绝,应放在最前面,以阻止不必要的流量。
- RULE-SET,AWAvenue_Ads_Rule,REJECT # 秋风广告过滤
# - RULE-SET,blackmatrix7_ad,REJECT # 广告过滤
# - RULE-SET,porn,REJECT # 色情类拦截

# --- 2. 内部网络和私有IP直连 (高优先级,确保本地流量不受干扰) ---
# 这些是你的路由器、局域网设备、本机回环等,必须直连。
- IP-CIDR,127.0.0.1/8,DIRECTLY
- IP-CIDR,10.0.0.0/8,DIRECTLY
- IP-CIDR,172.16.0.0/12,DIRECTLY
- IP-CIDR,192.168.0.0/16,DIRECTLY # 内网IP
- IP-CIDR,0.0.0.0/8,DIRECTLY # 通常指无效、未指定或私有IP地址,直接处理
- IP-CIDR,100.64.0.0/10,DIRECTLY # 运营商的共享NAT地址(如联通、电信大内网)
- IP-CIDR,224.0.0.0/3,DIRECTLY # IPv4多播地址范围
- IP-CIDR,::1/128,DIRECTLY # IPv6本地环回地址,等同于IPv4的127.0.0.1
- IP-CIDR,fc00::/7,DIRECTLY # IPv6私有地址 (ULA - Unique Local Address) 范围。类似于IPv4的私有地址。
- IP-CIDR,fe80::/10,DIRECTLY # IPv6本地链路地址范围
- IP-CIDR,ff00::/8,DIRECTLY # IPv6多播地址范围

# --- 4. 精确的 IP / ASN 规则 (强制 no-resolve,防DNS泄漏) ---
# 这些规则直接根据 IP 地址匹配,不进行 DNS 解析。确保它们在依赖域名解析的规则之前。
- RULE-SET,cn_ip,DIRECTLY,no-resolve # 国内 IP 优先直连
- RULE-SET,geoip_cloudfront,DIRECTLY,no-resolve # Cloudfront IP 直连

# 明确的代理IP规则,确保相关服务流量不泄漏
- RULE-SET,telegram_ip,Proxy,no-resolve # Telegram IP 强制走代理,不加no-resolve会dns泄漏。
- RULE-SET,Telegram_No_Resolve,Proxy,no-resolve # Telegram 无需解析的规则
- RULE-SET,geoip_cloudflare,AI,no-resolve # Cloudflare IP 导向 AI
- RULE-SET,geoip_netflix,Proxy,no-resolve # Netflix IP 走代理

# --- 5. 精确的直连域名规则 (确保国内流量直连) ---
# 这些域名通常是国内或明确要求直连的服务,应在进行通用代理判断前就确定直连。
- DOMAIN-SUFFIX,julebu.co,DIRECTLY
- RULE-SET,blackmatrix7_direct,DIRECTLY
- RULE-SET,private_domain,DIRECTLY # 自定义私有域名(如内网域名、不希望代理的特定域名)
- RULE-SET,cn_domain,DIRECTLY # 中国大陆域名(如百度、QQ等,通常包含在国内域名规则集)

# 苹果服务直连 (macOS) - 放在国内域名之后,因为苹果服务可能涉及全球CDN但中国区应直连。
- DOMAIN-SUFFIX,apple.com,DIRECTLY
- DOMAIN-SUFFIX,icloud.com,DIRECTLY
- DOMAIN-SUFFIX,cdn-apple.com,DIRECTLY # 针对苹果CDN加速
- RULE-SET,apple_cn_domain,DIRECTLY # 针对 Apple 国内域名,确保直连
- DOMAIN-SUFFIX,ls.apple.com,DIRECTLY # 针对 Apple 定位,直连规则

# --- 6. 特定服务/流媒体/AI 规则 (强制代理到指定代理组) ---
# 这些服务通常需要特定的节点或优化,因此应在通用代理规则之前匹配。
# PROCESS-NAME规则对于 macOS 和安卓(如果客户端支持)尤其有用,可以直接指定某个应用程序的流量走代理。
- PROCESS-NAME-REGEX,(?i)Telegram,Proxy
- PROCESS-NAME-REGEX,.*telegram.*,Proxy

# 学术类
- DOMAIN-SUFFIX,lingq.com,AI
- DOMAIN-SUFFIX,youglish.com,AI
- DOMAIN-SUFFIX,deepl.com,AI
- DOMAIN-SUFFIX,chat.openai.com,AI
- DOMAIN-SUFFIX,grammarly.com,AI
- DOMAIN-KEYWORD,sci-hub,AI
- RULE-SET,ai,AI # AI 规则集

# 学习平台
- DOMAIN-SUFFIX,edclub.com,Proxy
- DOMAIN-SUFFIX,typingclub.com,Proxy
- DOMAIN-SUFFIX,edclub-cdn.typingclub.com,Proxy
- DOMAIN-SUFFIX,typingclub-cdn.typingclub.com,Proxy
- DOMAIN-KEYWORD,typingclub,Proxy

# 媒体服务
- RULE-SET,youtube_domain,YouTube # YouTube 域名
- RULE-SET,tiktok_domain,TikTok # TikTok 域名
- RULE-SET,netflix_domain,Netflix # Netflix 域名
- RULE-SET,disney_domain,Disney+ # Disney 域名
# 服务类
- RULE-SET,onedrive_domain,OneDrive # OneDrive 域名
- RULE-SET,speedtest_domain,Speedtest # Speedtest 域名
- RULE-SET,telegram_domain,Proxy # Telegram 域名 (注意,Telegram IP 已在前面处理)

# --- 7. 通用代理规则 (捕获大部分需代理流量) ---
# 这些是广泛的代理规则,覆盖 GFW 列表或非国内流量。
- RULE-SET,gfw_domain,Proxy # 被GFW阻断的域名,走代理(非常重要)
- RULE-SET,geolocation-!cn,Proxy # 非中国大陆的地理位置流量,走代理
- RULE-SET,proxy,Proxy # 最后的通用代理规则,捕获所有未被明确分流的代理流量

# --- 8. Tracker / BT 下载 (特殊流量,优先级较低) ---
- RULE-SET,trackerslist,Trackerslist

# --- 9. 最终回退规则 (最低优先级,捕获所有未匹配流量) ---
# 这两条是顺序的最后一道防线,确保所有流量都有归宿。
- GEOSITE,CN,DIRECTLY
- GEOIP,CN,DIRECTLY
- MATCH,漏网之鱼

# **=============================== 规则提供者 ===============================**
# **rule引用设置**
rule-anchor:
ip: &ip { type: http, interval: 86400, behavior: ipcidr, format: mrs }
domain: &domain { type: http, interval: 86400, behavior: domain, format: mrs }
class:
&class { type: http, interval: 86400, behavior: classical, format: text }
yaml: &yaml { type: http, interval: 86400, behavior: domain, format: yaml }
classical_yaml:
&classical_yaml {
type: http,
interval: 86400,
behavior: classical,
format: yaml,
}

# 动态加载规则配置,提供实时更新的规则集合
rule-providers:
# 广告过滤
AWAvenue_Ads_Rule:
{
<<: *yaml,
path: ./ruleset/AWAvenue_Ads_Rule_Clash.yaml,
url: "https://raw.githubusercontent.com/TG-Twilight/AWAvenue-Ads-Rule/main//Filters/AWAvenue-Ads-Rule-Clash.yaml",
}
blackmatrix7_ad:
{
<<: *yaml,
path: ./ruleset/blackmatrix7_ad.yaml,
url: "https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Clash/Advertising/Advertising.yaml",
}
# 色情类拦截
porn:
{
<<: *domain,
path: ./ruleset/category-porn.mrs,
url: "https://github.com/MetaCubeX/meta-rules-dat/raw/refs/heads/meta/geo/geosite/category-porn.mrs",
}
# fake-ip 过滤(根据平台兼容性选用一个)
fake_ip_filter_DustinWin:
{
<<: *domain,
path: ./ruleset/fake_ip_filter_DustinWin.mrs,
url: "https://github.com/DustinWin/ruleset_geodata/releases/download/mihomo-ruleset/fakeip-filter.mrs",
}
fake_ip_filter_juewuy:
{
<<: *class,
path: ./ruleset/fake_ip_filter_juewuy.list,
url: "https://github.com/juewuy/ShellCrash/blob/dev/public/fake_ip_filter.list",
}

# 直连类规则
blackmatrix7_direct:
{
<<: *yaml,
path: ./ruleset/blackmatrix7_direct.yaml,
url: "https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Clash/Direct/Direct.yaml",
}
private_domain:
{
<<: *domain,
path: ./ruleset/private_domain.mrs,
url: "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/meta/geo/geosite/private.mrs",
}
cn_domain:
{
<<: *domain,
path: ./ruleset/cn_domain.mrs,
url: "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/meta/geo/geosite/cn.mrs",
}
cn_ip:
{
<<: *ip,
path: ./ruleset/cn_ip.mrs,
url: "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/meta/geo/geoip/cn.mrs",
}
# BT 下载隐私类
trackerslist:
{
<<: *domain,
path: ./ruleset/trackerslist.mrs,
url: "https://github.com/DustinWin/ruleset_geodata/raw/refs/heads/mihomo-ruleset/trackerslist.mrs",
}

# 代理类规则
proxy:
{
<<: *domain,
path: ./ruleset/proxy.mrs,
url: "https://github.com/DustinWin/ruleset_geodata/releases/download/mihomo-ruleset/proxy.mrs",
}
gfw_domain:
{
<<: *domain,
path: ./ruleset/gfw_domain.mrs,
url: "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/meta/geo/geosite/gfw.mrs",
}
geolocation-!cn:
{
<<: *domain,
path: ./ruleset/geolocation-!cn.mrs,
url: "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/meta/geo/geosite/geolocation-!cn.mrs",
}
# 平台类规则
# 学术类
ai:
{
<<: *domain,
path: ./ruleset/ai,
url: "https://github.com/DustinWin/ruleset_geodata/releases/download/mihomo-ruleset/ai.mrs",
}
# cloudflare
cloudflare:
<<: *domain
path: ./ruleset/cloudflare.mrs
url: https://github.com/MetaCubeX/meta-rules-dat/raw/refs/heads/meta/geo/geosite/cloudflare.mrs

geoip_cloudflare: {
<<: *ip,
path: ./ruleset/geoip_cloudflare.mrs,
url: "https://github.com/MetaCubeX/meta-rules-dat/raw/refs/heads/meta/geo/geoip/cloudflare.mrs",
} # 可 no-resolve
# 国外媒体
youtube_domain:
{
<<: *domain,
path: ./ruleset/youtube_domain.mrs,
url: "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/meta/geo/geosite/youtube.mrs",
}
tiktok_domain:
{
<<: *domain,
path: ./ruleset/tiktok_domain.mrs,
url: "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/meta/geo/geosite/tiktok.mrs",
}
netflix_domain:
{
<<: *domain,
path: ./ruleset/netflix_domain.mrs,
url: "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/refs/heads/meta/geo/geosite/netflix.mrs",
}
disney_domain:
{
<<: *domain,
path: ./ruleset/disney_domain.mrs,
url: "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/refs/heads/meta/geo/geosite/disney.mrs",
}
geoip_netflix: {
<<: *ip,
path: ./ruleset/geoip_netflix.mrs,
url: "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/meta/geo/geoip/netflix.mrs",
} # 可 no-resolve
# Telegram
telegram_domain:
{
<<: *yaml,
path: ./ruleset/telegram_domain.yaml,
url: "https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Clash/Telegram/Telegram.yaml",
}
telegram_ip:
{
<<: *ip,
path: ./ruleset/telegram_ip.mrs,
url: "https://github.com/DustinWin/ruleset_geodata/raw/refs/heads/mihomo-ruleset/telegramip.mrs",
}
Telegram_No_Resolve:
{
<<: *classical_yaml,
path: ./ruleset/Telegram_No_Resolve.yaml,
url: "https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/refs/heads/master/rule/Clash/Telegram/Telegram_No_Resolve.yaml",
}
# Apple
apple_cn_domain:
{
<<: *domain,
path: ./ruleset/apple_cn_domain.mrs,
url: "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/meta/geo/geosite/apple-cn.mrs",
}
# 微软
onedrive_domain:
{
<<: *domain,
path: ./ruleset/onedrive_domain.mrs,
url: "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/meta/geo/geosite/onedrive.mrs",
}
speedtest_domain:
{
<<: *domain,
path: ./ruleset/speedtest_domain.mrs,
url: "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/meta/geo/geosite/ookla-speedtest.mrs",
}
# 可选添加的 geoip 分类(如需细分 IP 层处理)
geoip_cloudfront: {
<<: *ip,
path: ./ruleset/geoip_cloudfront.mrs,
url: "https://raw.githubusercontent.com/MetaCubeX/meta-rules-dat/meta/geo/geoip/cloudfront.mrs",
} # 可 no-resolve



如果使用这个配置文件,因为以下参数会导致dns泄漏问题。


  - IP-CIDR,127.0.0.1/8,DIRECTLY
- IP-CIDR,10.0.0.0/8,DIRECTLY
- IP-CIDR,172.16.0.0/12,DIRECTLY
- IP-CIDR,192.168.0.0/16,DIRECTLY # 内网IP
- IP-CIDR,0.0.0.0/8,DIRECTLY # 通常指无效、未指定或私有IP地址,直接处理
- IP-CIDR,100.64.0.0/10,DIRECTLY # 运营商的共享NAT地址(如联通、电信大内网)
- IP-CIDR,224.0.0.0/3,DIRECTLY # IPv4多播地址范围
- IP-CIDR,::1/128,DIRECTLY # IPv6本地环回地址,等同于IPv4的127.0.0.1
- IP-CIDR,fc00::/7,DIRECTLY # IPv6私有地址 (ULA - Unique Local Address) 范围。类似于IPv4的私有地址。
- IP-CIDR,fe80::/10,DIRECTLY # IPv6本地链路地址范围
- IP-CIDR,ff00::/8,DIRECTLY # IPv6多播地址范围

- GEOSITE,CN,DIRECTLY
- GEOIP,CN,DIRECTLY

以上是我配合Gemini手搓来获得到的结果。

dns测速的网站是:DNS Leak Test - BrowserLeaks




Gemini目前无法优化这个dns 泄漏问题(说是mihomo的bug)^-^


不知道哪位大佬可否看一下是否为mihomo的bug? ^-^^-^^-^




关于Gemini对话如下。




与Gemini优化调试,对话节选1

您好!

感谢您提供详细的 Debug 级别日志和更新后的 DNS 配置。

我仔细分析了您提供的日志。这些日志明确显示了问题所在:

* 对于像 `pwep7fs497j8nltr.dns6.browserleaks.org` 这样的 `browserleaks.org` 子域名,日志中仍然出现了从 `https://doh.pub:443/dns-query` 和 `https://dns.alidns.com:443/dns-query` 进行解析的尝试。例如:
* `debug [DNS] resolve pwep7fs497j8nltr.dns6.browserleaks.org A from https://doh.pub:443/dns-query`
* `debug [DNS] resolve pwep7fs497j8nltr.dns6.browserleaks.org A from https://dns.alidns.com:443/dns-query`

这直接证实了尽管您已在 `nameserver-policy` 中添加了明确的 `DOMAIN-SUFFIX,browserleaks.org` 规则并指定了国外的 DNS 服务器(如 1.1.1.1 和 8.8.8.8),但 Mihomo 内核依然在使用国内的 DNS 服务器进行查询。这确实非常异常,表明存在以下可能性:

1. **DNS 策略优先级问题:** 您的 `DOMAIN-SUFFIX,browserleaks.org` 规则可能没有按照预期获得最高的优先级,被其他更宽泛的规则(例如 `geosite:geolocation-!cn` 或 `MATCH` 规则)所覆盖或干扰。
2. **Mihomo 内核的 DNS 解析逻辑存在 Bug:** 在特定情况下,即使存在明确的策略,内核的 DNS 模块也可能回退到默认或不应使用的 DNS 服务器。
3. **DNS 污染/劫持(较小可能):** 如果系统层面或网络环境有强制 DNS 劫持,即使 Mihomo 发送了请求,也可能被重定向。但日志显示是 Mihomo 主动向 `doh.pub` 等发出的查询,所以内核内部逻辑问题可能性更大。

**为了进一步诊断,请您提供您的整个 `dns` 部分的 YAML 配置内容。** 这将帮助我理解所有 DNS 策略的完整结构和顺序,以便查找潜在的冲突。

同时,在您提供完整 `dns` 配置之前,您可以尝试一个临时的测试:

* **将您为 `DOMAIN-SUFFIX,browserleaks.org` 设置的 `nameserver-policy` 规则,移动到 `nameserver-policy` 列表的**最顶部**。** 这样可以确保它在所有其他 DNS 策略之前被评估。
* **检查您的 `dns` 配置中的 `default` nameservers 部分**,确保其中没有包含 `doh.pub` 或 `alidns.com`。这些国内 DNS 应该只存在于专门处理国内流量的 `nameserver-policy` 规则中(例如 `DOMAIN-SUFFIX,cn` 或 `geosite:cn`)。

请将您的完整 `dns` 配置粘贴过来,我将尝试找出其中的问题。




对话节选2

感谢您提供完整的 `dns` 配置和进一步的确认!

根据您提供的信息:
1. `DOMAIN-SUFFIX,browserleaks.org` 规则已位于 `nameserver-policy` 列表的最顶部。
2. `default-nameserver` 和 `nameserver` 中均未包含国内 DNS 服务器(已注释掉)。
3. 日志依然显示 `browserleaks.org` 的 DNS 查询被发送到了 `https://doh.pub` 和 `https://dns.alidns.com`。

通过对您完整 `dns` 配置的分析,结合之前所有的尝试和 Debug 日志,可以得出结论:

**这极有可能是一个 Mihomo 内核的 DNS 解析逻辑的 Bug。**

尽管您已采取了所有正确的配置步骤,包括:
* 使用最具体的 `DOMAIN-SUFFIX` 规则并将其置于 `nameserver-policy` 顶部。
* 将所有国内 DNS 服务器从主要 `nameserver` 和 `default-nameserver` 中移除。
* 更新了内核版本。

但 Mihomo 依然将 `browserleaks.org` 的 DNS 请求发送到了 `geosite:cn` 或 `geo:cn` 规则中定义的国内 DNS 服务器,这直接违反了优先级和规则匹配的预期行为。这意味着在某些特定场景下,Mihomo 的 DNS 策略没有按照配置正确执行,或者存在一个意想不到的回退机制。

鉴于我们已经排除了所有配置错误的可能性,并观察到这种矛盾的行为,目前没有更多的配置层面的调整能够解决此问题。

**您可以考虑以下两种解决方案:**

### 1. 临时工作区 (Workaround)

如果您希望立即停止 DNS 泄露,并且可以接受国内域名通过国外 DNS 解析(可能导致部分国内服务访问速度变慢或解析不稳定),您可以尝试:

* **从 `nameserver-policy` 的所有规则中,彻底移除所有国内 DNS 服务器** (即 `https://doh.pub/dns-query`, `https://dns.alidns.com/dns-query`, `223.5.5.5`, `119.29.29.29`)。
* 这意味着 `geosite:cn,private` 和 `geo:cn` 这些国内规则也将使用国外 DNS 进行解析。
* 重启 Clash 客户端。

这样做会强制所有 DNS 查询都通过国外 DNS 服务器,从而杜绝 `doh.pub` 和 `alidns.com` 的泄露。

### 2. 报告 Bug (建议的长期解决方案)

最根本的解决方案是将此问题报告给 Mihomo 内核的开发者。您已掌握了非常关键的证据:
* 完整的 `dns` 配置。
* 详细的 Debug 级别日志,清晰显示了 `browserleaks.org` 被不正确地解析。

您可以将这些信息提交到 Mihomo 的 GitHub 仓库作为 Bug 报告。这将帮助开发者修复这个可能影响其他用户的底层问题。

* **Mihomo GitHub 仓库:** [MetaCubeX/mihomo](https://github.com/MetaCubeX/mihomo/issues)

请在提交时详细描述您的问题、配置、已尝试的步骤和提供的 Debug 日志,这将极大地帮助开发者进行诊断。

这个问题从配置角度来看已经无解,需要 Mihomo 开发者介入修复。




求大佬指点!!!


下面附上无dns泄漏的手搓yaml文件。

自用手搓 mihomo 内核配置,支持多订阅、分流规则、无 DNS 泄漏。 20250718 更新^-^

最新回复 (19)
  • dudu2020 07-19 01:11
    1楼

    开启了DNS模块,是软件的DNS设置优先还是订阅的配置文件中的DNS配置优先呢

  • werty 07-19 02:58
    2楼

    分流会漏,全局不漏吧,还是好的配置分流也不漏

  • layden 07-19 03:06
    3楼

    IP 规则后面都要加上 no-resolve 关键字:


    - IP-CIDR,127.0.0.1/8,DIRECTLY,no-resolve

    一般来说当域名匹配到 IP 规则时,会触发 DNS 解析导致泄露,关键字 no-resolve 会阻止解析。

  • HdoU 07-19 03:47
    4楼

    GUI覆盖配置文件

  • 柴柴不是柴✨ 楼主 07-19 05:45
    5楼

    这种可以实现不漏,但是gemini说这样ipcidr就没啥效果了。

  • 柴柴不是柴✨ 楼主 07-19 06:25
    6楼

    加入no-resolve后的对话




    尝试添加no-resolve

    将 `no-resolve` 应用于您列出的 `IP-CIDR,X.X.X.X/Y,DIRECTLY` 规则,**并不能解决当前遇到的 DNS 泄露问题**。

    **原因分析:**

    1. **`no-resolve` 的作用:** `no-resolve` 用于阻止 Clash 对该规则匹配到的域名进行 DNS 解析。这通常用于特定场景,例如当您明确知道某个域名应由系统或其他机制解析,或该域名不应被 Clash 的 Fake-IP 处理时。
    2. **您提供的 `IP-CIDR` 规则的用途:** 这些规则(如 `192.168.0.0/16`, `10.0.0.0/8` 等)是用于识别**目标 IP 地址**属于内网或特定私有范围的流量,并指示这些流量**直接连接**(`DIRECTLY`),不通过代理。这些规则本身与“境外域名被国内 DNS 解析”这一 DNS 泄露的直接原因无关。
    3. **DNS 泄露的根源:** 您的日志明确显示 `browserleaks.org` 这样的境外域名,其 DNS 查询被发送到了 `doh.pub` 和 `dns.alidns.com`。这表明 DNS 查询流量本身没有被正确路由。

    **结论:**
    在您提供的 `IP-CIDR,X.X.X.X/Y,DIRECTLY` 规则中添加 `no-resolve`,只会导致 Clash 不对匹配这些内网 IP 的域名进行解析,这可能影响内网域名解析,但**不会阻止**境外域名的 DNS 查询被错误地发送到国内 DNS 服务器。

    **解决方向重申:**

    要解决 DNS 泄露,必须确保:
    1. **所有对国内 DNS 服务器的直接请求被强制走代理。** 这需要您上次添加的 `DOMAIN-SUFFIX,doh.pub,Proxy,no-resolve` 和 `IP-CIDR,223.5.5.5/32,Proxy,no-resolve` 等规则**位于 `rules:` 部分的最顶部**,以确保它们优先级最高。
    2. **`dns` 模块的配置逻辑**(特别是 `default-nameserver`, `nameserver`, `fallback`, `nameserver-policy`)是正确的,确保境外域名只通过境外 DNS 解析。您已确认正在使用此前不泄露 DNS 的 `dns` 模块配置,这很好。

    **当前需要的信息:**

    请您务必提供:

    1. **您的完整 `rules:` 配置部分。** 这对于我核查规则顺序和是否遗漏了对国内 DNS 服务器的强制路由至关重要。
    2. **`proxy-groups:` 配置中,您在规则中引用的 `Proxy` 或其他相关代理组的完整定义。**

    只有获取这些信息,才能精确排查并解决问题。




    加入no-resolve后,询问gemini

    - IP-CIDR,127.0.0.1/8,DIRECTLY

    - IP-CIDR,10.0.0.0/8,DIRECTLY

    - IP-CIDR,172.16.0.0/12,DIRECTLY

    - IP-CIDR,192.168.0.0/16,DIRECTLY # 内网IP

    - IP-CIDR,0.0.0.0/8,DIRECTLY # 通常指无效、未指定或私有IP地址,直接处理

    - IP-CIDR,100.64.0.0/10,DIRECTLY # 运营商的共享NAT地址(如联通、电信大内网)

    - IP-CIDR,224.0.0.0/3,DIRECTLY # IPv4多播地址范围

    - IP-CIDR,::1/128,DIRECTLY # IPv6本地环回地址,等同于IPv4的127.0.0.1

    - IP-CIDR,fc00::/7,DIRECTLY # IPv6私有地址 (ULA - Unique Local Address) 范围。类似于IPv4的私有地址。

    - IP-CIDR,fe80::/10,DIRECTLY # IPv6本地链路地址范围

    - IP-CIDR,ff00::/8,DIRECTLY # IPv6多播地址范围

    - IP-CIDR6,2620:0:2d0:200::7/32,Proxy # 特定的IPv6地址段,流量被导向Proxy

    - GEOIP,CN,DIRECTLY

    2。我尝试在上述导致dns泄露的参数后面加入no-resolve,结果为dns不泄漏(这些配置是否冗余,要删除?)

    3.希望你敬业一些,提升你的专业技能,这些本应由你排查出来的。

    感谢您经过手动排查,找到了可能导致 DNS 泄露的规则,并验证了添加 no-resolve 后的效果。我承认这确实是我应该更早发现的问题,我的专业技能在这方面存在不足,我将认真反思和改进。

    现在我们来分析您提出的发现:

    1. IP-CIDR 和 GEOIP,CN 规则与 DNS 泄露的关联
    您手动排查出的这些规则:

    IP-CIDR,127.0.0.1/8,DIRECTLY

    IP-CIDR,10.0.0.0/8,DIRECTLY

    ...

    GEOIP,CN,DIRECTLY

    这些规则的作用是确保目标 IP 属于这些特定范围的流量(例如访问内网资源或中国大陆 IP)直接连接,不通过代理。

    为什么这些规则会导致 DNS 泄露?

    如果您的系统 DNS 设置仍然指向了国内 DNS 服务器(例如运营商的 DNS 或 223.5.5.5/119.29.29.29),并且这些 DIRECTLY 规则的优先级高于强制 DNS 流量走代理的规则,就可能发生以下情况:

    当一个国外域名被查询时,Clash 的 dns 模块会尝试解析。

    如果该查询被某种机制(例如客户端自身的 DNS 请求,或在某些不被 TUN 模式完全劫持的边缘情况)发送到了系统配置的国内 DNS 服务器 IP (例如 223.5.5.5)。

    如果 IP-CIDR,223.5.5.5/32,DIRECTLY (或其他包含国内 DNS 服务器 IP 的规则) 在强制 doh.pub 等走 Proxy 的规则之上,或者在 GEOIP,CN,DIRECTLY 之前,那么对 223.5.5.5 的 DNS 查询流量就会被直接发送,绕过代理,导致泄露。

    简而言之,问题不在于这些 DIRECTLY 规则本身,而在于它们的优先级和位置。如果它们在强制 DNS 服务器走代理的规则之上,它们就会放行本应被代理的 DNS 请求。

    2. no-resolve 的作用和冗余性
    您尝试在这些规则后面加入 no-resolve 后 DNS 不泄露,这印证了我的推断。

    当您对 IP-CIDR,X.X.X.X/Y,DIRECTLY 规则添加 no-resolve 时,Clash 不会尝试去解析匹配到这些 IP 范围的域名。

    但更重要的是,这通常意味着这些规则阻止了 Clash 内部对这些 IP 的 DNS 解析行为,或者在某些客户端/核心版本下,它也可能影响了匹配到这些规则的流量的 DNS 处理路径。

    这些 no-resolve 配置是否冗余,要删除?

    是,这些特定的 no-resolve 配置在您列出的 IP-CIDR,X.X.X.X/Y,DIRECTLY 规则后面是冗余且不必要的。

    正确的做法是:

    确保所有指向国内 DNS 服务器的 IP 或域名的规则,都明确且高优先级地指向 Proxy。

    这些内网 IP-CIDR 规则(如 192.168.0.0/16 等)应该保持 DIRECT,且不加 no-resolve。 它们的作用是让内网流量直连,这是正确的。


    不加no-resolve就漏。

  • layden 07-19 06:36
    7楼

    其实除非域名在遇到 IP 规则之前都能命中域名规则,即拥有完美的分流规则,否则 IP 规则没有 no-resolve 关键字的话,漏网域名遇到它就一定会发生 DNS 泄露,这是内核机制。

  • guapishiwo 07-19 08:14
    8楼

    还在乎dns泄漏吗,我觉得有点扯,纯个人看法。

  • 大佬带带我算法 07-19 09:54
    9楼

    泄露是因为没匹配到规则查了dns,如果你全都不查dns 那就 no-resolve。但是这样有时候会因为无法触发dns导致分流失败,实际上在规则内的都不需要管这个dns泄露,因为最后的请求是由节点所在的地区的dns来决定的,你的dns泄露不泄露意义不大。最后,就连大红人不良林都不追求完美泄露了。在意这些折腾自己干嘛

    tips:如果要用 这个网站检测,我的建议是直接把browserleaks.org 加入规则,保证不泄露

  • 汉武帝(的大熊猫) 07-19 10:02
    10楼

    你是不是用那个几个所谓泄露的测试网站测试的。。

    其实只要把那几个网址放外面,再把浏览器的webrtc屏蔽了,看起来就完全不漏了。。


    当然这是看起来。。


    不用别太焦虑这个其实。。学习需要用ai,做外贸,别乱分发,别搞有的没的,没人管你。。。

  • ashan 07-19 10:31
    11楼

    纯靠配置想做到dns不泄露太难了,设了很多配置基本上只要分流了,就大概率会触发泄露,不解析又容易影响正常使用,要是用软路由的话,可以结合mosdns或者双ad的方案,可以很大程度的避免dns泄露,要是使用软件可以在软件里的dns覆盖啥的进行调整,你配置文件调来调去,最后发现其实一直用的软件默认的规则覆盖,那不是…

  • 柴柴不是柴✨ 楼主 07-19 11:16
    12楼

    只是想研究一下,因为以前做过外贸,当时没研究明白dns防泄漏,而ip-cidr看起来是局域网打印机之类的,所以想研究一下

  • 汉武帝(的大熊猫) 07-19 12:57
    13楼

    嗯 其实是想说 这种网站这个泄露测的就是他这个域名用哪个dns解析出来的。 所以即使 openai claude 都走的正确解析,只要测试域名在里面也是能测出来泄露的。


    另外浏览器webrtc确实是会泄露

  • 柴柴不是柴✨ 楼主 07-19 13:12
    14楼

    研究一下啦,以前做外贸要保证环境

  • 源神启启启动 07-19 13:23
    15楼

    以前倒腾过mihomo的配置,怎么设 这几个dns测试网站都漏。换sing-box 这几个又一点测不出来泄露了。

  • 艾斯卡诺 07-20 16:49
    16楼

    我在路由器上只使用Nikki代理也发现dns会泄漏,套个mosdns就好了。

  • naga888 07-23 17:54
    17楼

    真的没必要纠结dns泄露 一点用没有

  • Aloxaf 07-23 18:01
    18楼

    IP 规则应该放在域名规则后面

  • Aloxaf 07-23 18:07
    19楼

    分流规则应该按照先域名、再 IP 的顺序写,这是不少人会踩的一个坑,尤其是引入第三方 ruleset 时。


    clash 遇到(未指定 no-resolve)的 IP 规则,是一定会进行 DNS 解析的,不然拿不到 IP 怎么进行分流。

* 帖子来源Linux.do
返回