Avatar

Mihomo 自用配置

PublishedUpdatedcomments

1. 缘由

clash系列算是自己接触代理最早的内核了，虽然期间也有接触过v2ray，不过有很长一段时间我都是以clash为主用。直到 23 年换成 iPhone 后，我才开始使用 Surge，因为其在ios/mac上确实有更好的体验（且配置写起来也相对容易一些）。后面有一段时间又折腾了sing-box了（不过由于一些客观原因，后续不会再折腾 sing-box 了），最近闲下来，觉得有必要写一个关于mihomo的配置以及想法。

对于一些用户想直接看全部配置文件的(不想看我碎碎念的)可以直接到仓库中查看。

以下都以仓库中的 mihomo_single.yaml 为例。

2. 全局配置

先贴配置：

mixed-port: 7897
allow-lan: true
mode: rule
log-level: warning
ipv6: false
find-process-mode: strict
unified-delay: true
tcp-concurrent: true
global-client-fingerprint: chrome

# ## 如果使用的是裸核，需要将下面的注释去掉，方便ui界面的使用
# external-controller: 0.0.0.0:9988
# external-ui: ui
# external-ui-url: 'https://github.com/Zephyruso/zashboard/releases/latest/download/dist.zip'
# secret: "yyhhyyyyyy"

profile:
  store-selected: true
  store-fake-ip: true

解释：

mixed-port : 混合代理端口。如：http或者socks代理时，直接用这个端口就行

allow-lan : 允许局域网连接。如：允许其他设备经过 Mihomo的代理端口访问互联网

mode : 选用什么模式运行mihomo。可选值: rule 、 global 、 direct 大部分情况下我们都用 rule 即规则模式，根据我们的分流配置来使用

log-level : 日志输出级别。

ipv6 : 非刚需就不开。(目前的网络环境还是推荐在ipv4环境下，避免产生一些奇怪的问题，如果有需求可以开启)

find-process-mode : 控制 Mihomo 是否识别连接所属的进程，并按进程维度进行规则匹配。使用默认即可。

unified-delay : 统一延迟。测出来的结果“是你希望看到的，也就是时延会更快”

tcp-concurrent : TCP并发，当有多个 dns 时，会解析出所有 IP 地址进行连接，默认使用第一个解析成功的 IP。

external-controller : ui界面访问端口。

external-ui : ui界面在本地文件夹的命名

external-ui-url : 使用的ui界面的url地址

secret : api的密钥，建议都设置上

profile : 缓存 分别：1. 储存 API 对策略组的选择，以供下次启动时使用 2. 储存 fakeip 映射表，域名再次发生连接时，使用原有映射地址

这部分如果不知道你想要的效果是什么，请与我一致不做修改

3. DNS

在开始之前，大家可以先看一下Sukka的[《是什么，为什么，怎么做 —— 谈谈 DNS 泄漏、CDN 访问优化与 Fake IP》]这篇文章(https://blog.skk.moe/post/lets-talk-about-dns-cdn-fake-ip/)

3.1 DNS 泄露？

说到DNS，肯定就得说到 DNS泄露 了。

其实我自己也有一段时间陷入过 DNS泄露 这个名词的”恐怖折腾“中，现在想想其实真的有点笨。为什么呢？

首先先简单解释下什么是 DNS泄露 简单理解，当你在访问一个需要代理才能访问的域名，比如google.com；我们在获取其ip的过程中，不是使用的代理的服务器的dns去解析 google.com 这个域名 ，而是使用你当前所用的网络环境的DNS，对google.com这个域名进行解析。那么这个过程就是所谓的 DNS泄露 。

再者还有一部分人会说，会用 DNS解析 来让网站来描绘用户的画像？这点更是天方夜谈了，除了 google 的DNS节点能基本遍布全世界，其他家的DNS节点 不是这个国家缺，就是那个国家缺的。如果你是网站的运营者，那么你会用这个来描绘用户的画像吗？ 比如你在一个很偏僻的国家 A 这个国家 google 没有DNS节点 ，那你如果用google的DNS来进行DNS解析，一般会给你找邻国附近 B 国的DNS节点，那么网站的运营者就会以此来判断你是 B 国的人吗？ 肯定不会的，这太扯了。

他有什么危害，其实看了这么多文章，都在说可能会 "导致用户的真实IP地址和网络活动可能被泄露给第三方"。 但是试问现在的网民全世界有大，有必要说盯着“您”的网络活动吗？ 应该不至于吧哈哈 。再者，其实当规则写好，遵循后文我描述的方式，那么 DNS 泄露既能最大程度上规避。

再来个简单的例子，你会说闽南语，但是我可以直接判断你是会讲闽南语地区的人吗？ 也肯定不会，因为有可能你是后天学习的。因此，这是同理的。

因此 DNS泄露 其实是有一定危言耸听的成分在里面的， 正确的叫法 应该是 DNS 出口查询。

本质上来说，你DNS的出口的IP和你网络的出口IP的地理位置是否一致，可以很大程度的决定，你的CDN解析是不是最优解。 也就是说你与你访问的那个网站，能否有更好的网络通信效果。

综上，DNS泄露 这个名词相信已经有了更好的认识，看到这里，你还会觉得它的问题特别大吗？还会很膈应你么？

当然，这是我自己认可的观点，如果你有自己认可的观点，那按照你所认可的观点来理解就好了。我只是将我自己认可的观点讲述出来罢了。说到底，在世界巨大的网络池子中，其实最上游一定会有日志记录的。比如你使用的机场，那机场是有日志记录的；你说你自建，那对应的 vps 厂商也是会有日志记录的。哪天真的需要溯源你的网络日志的话，那其实你也是躲避不过的。

3.2 DNS选择

能看到这里，说明已经对 DNS泄露 已经没那么排斥了。接下来，有这么多的 DNS 服务厂商要怎么选择？ 相信大家头也大，为什么选择阿里，为什么选择腾讯，为什么选择 cloudflare 等等，接下来简单阐述下。

在开始前，希望你能明白一件事，运营商的DNS服务，蛮不错，延迟一定是所有厂商里，排名top的！（有点绝对哈，但是绝大多数都是排top是肯定的）。但是，有前提，分流必须写好，且国内相对文明的网络环境下走运营商DNS一点问题都没，但是国外或者不文明的网络环境的就有问题了。

这里要提一嘴运营商的DNS在一定情形下，蛮不讨人喜的，比如DNS拦截，偷偷给你上广告等。但是正常国内域名使用自家运营商的DNS进行解析效果还是很不错的（主要是真的很快），因此做推荐。当然，如果为了省事，那肯定直接用公共DNS即可，当然推荐使用加密DNS。

至于公共DNS，国内的阿里或者腾讯直接用就好，如果硬要说谁稳定点，那阿里肯定是稍胜一筹的，毕竟做这块很久了，老大哥了。但是如果用这种公共DNS遇到特殊时期的时候，可能不同的DNS厂商会“打架”，会出现阿里解析阿里家的没有问题，但是解析别家的就有问题了。这方面，运营商提供的 DNS 就没这个问题，还是相对公平公正的。这就是运营商 DNS 服务 为什么好的其中一个原因。

至于国外比较权威的就是cloudflare和google咯，一般这两家也会比较公平公正，我一般如果要用的话这两家都会放在配置里（不过我一般不用，因为我用 fake-ip）。

加密 DNS 额外提一嘴，阿里和腾讯都有各自的付费加密 DNS，但是每个月都有免费额度。对于个人用户而言一般是够用，我是使用的付费加密 DNS 服务，没有使用他们的公共加密 DNS 服务。

3.3 DNS配置

说了这么多，先贴配置

dns:
  enable: true
  prefer-h3: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  # fake-ip-filter 这部分内容相对较长，请看仓库
  nameserver:
    # 网络环境文明的话推荐直接使用运营商的DNS服务器 或者 如果知道自己上游就是运营商DNS的情形下就使用
    - system
    - https://223.5.5.5/dns-query
    - https://doh.pub/dns-query
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
    - https://doh.pub/dns-query

简单说一下重点的几个配置的作用吧

nameserver ：默认的域名解析服务器。

默认都用他来解析域名。 这边我是放了一个自己系统的DNS服务（一般都是拨号的路由/光猫下发的运营商 DNS，不排除部分路由自己修改了），外加一个阿里的doh及一个腾讯的doh。为什么不两个都写运营商的DNS服务呢，因为我当地就一个DNS服务，所以只能拿个阿里来备选。不过一般也是会走入运营商DNS解析的。因为他最先返回解析结果，这样子就会优先使用。

这里需要额外提一点，如果是在公司等公共场合下，建议不要使用system (也就是上游下发的DNS)或者非加密的DNS。这种场合下以加密DNS的使用为主。

说到这里还需要简单解释下mihomo的DNS解析原理，mihomo收到一个域名后，会并发的把需要解析的域名同时向你填写的所有上游DNS服务器发送请求，最后看谁最先返回结果就用谁的结果。那只要你用的是当地的运营商的DNS，那么大概率是比较快的。因此绝大多数优先返回的是使用的运营商返回的DNS。

proxy-server-nameserver ：代理节点域名解析服务器，仅用于解析代理节点的域名。有且只会用在解析代理节点的域名。

这边最好就是使用国内的公共DNS，避免你节点的域名被污染了，使用运营商DNS解析的结果不准确（虽然域名污染后，公共 DNS 也不一定准确）。

贴一张Mihomo的DNS解析流程

DNS 解析流程

我的方案只写到了nameserver 和 proxy-server-nameserve，那这边简单介绍下 nameserver-policy 和 fallback 的作用吧

nameserver-policy 这个其实就是dns的分流规则

比如 'rule-set:TENCENT': https://doh.pub/dns-query 也就是你规则集中，是腾讯的域名都走腾讯自家的DNS服务

这个实际上就是一个道理 自家人不会伤害自家人 也就是用自家的DNS来解析自家的域名，出来的结果肯定不会有啥大问题

也可以把阿里等厂商的 DNS mapping放进来 这样的话就可以确保 自家人不会伤害自家人 ，但是我觉得没必要就是（

fallback 和 fallback-filter ：这两个是一起用的就拿来一起讲了。

先给定一份yaml吧

nameserver:
  - 运营商DNS（如果确定上游是运营商DNS的话 直接用 system）
  - https://223.5.5.5/dns-query
fallback:
  - tls://8.8.4.4
  - tls://1.1.1.1
fallback-filter:
  geoip: true
  geoip-code: CN

解释下Mihomo的解析过程（直接从nameserver-policy没匹配到开始）：

域名在 ns-policy 没匹配到后，会并发去向 nameserver 和 fallback 获取DNS解析结果， nameserver 一般都是国内的DNS服务，所以一般都会优先获取到结果， fallback 会稍微晚一些，但是一旦填写了 fallback 后，一定会等待 fallback 解析返回出来IP的结果，并且会走入 fallback-filter 进行判断，这边的例子就是开启geoip检测，且geoip-code也就是国家是CN。也就是会拿 nameserver 解析出来的ip结果与geoip数据库进行匹配，如果解析的是CN的ip，那么就直接用 nameserver 解析出来的结果，如果nameserver 解析出来的ip结果不是CN，那么就会用 fallback 的解析结果。

这边要特别注意一个地方，就是如果开启了 fallback 哪怕 nameserver 解析的再快都需要等待 fallback 的解析结果。并且 fallback-filter 比较依赖geo这个数据库（但是看了一些文章觉得其中的geosite应该是有一定的问题的）具体问题如下（该来源为 Sukka）：

因为 dnsmasq-china-list 设计之初是为国内域名的 DNS 解析优化、完全不适用于流量分流（dnsmasq-china-list 只检查域名的权威 DNS 服务器，因此有部分海外域名、因为 DNS 服务器位于中国大陆、依然被包含在 accelerated-domains.china.conf 中）。因此，Loyalsoldier/v2ray-rules-dat 和 MetaCubeX/meta-rules-dat 项目的 GEOSITE 规则使用 dnsmasq-china-list 作为上游数据来源 是大错特错的。

因此学习 Sukka 的文章后，我不是很喜欢用这个系列(

所以 fallback 在现有的环境下我是不会去使用他的。

nameserver-policy：

举例下，就是阿里的域名或者服务器，全部走阿里的DNS；同理腾讯等其他厂商也是如此。

请到 以下链接 自行复制内容 粘贴到 自己的 配置文件中使用即可。

另外，有自动的代码，但是由于时间有限没有写到action中，请有能力的同学自行运行python脚本。代码以及说明在我的仓库中。

至此，DNS部分我认为已经足够了

4. 域名嗅探

配置：

sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080-8880]
      override-destination: true
    TLS:
      ports: [443, 8443]
    QUIC:
      ports: [443, 8443]
  skip-domain:
    - Mijia Cloud
    - '+.push.apple.com'

简易理解如下图（只是场景描述，核心为拿 SNI 使得分流更精确）：

用户在 App 里访问：youtube.com
        │
        ▼
App 发起连接
        │
        ├─ 情况 A：Mihomo 一开始就拿到了域名
        │          例如：DNS / 连接信息里已有 youtube.com
        │
        └─ 情况 B：Mihomo 一开始只看到 IP
                   例如：142.250.xx.xx:443
                   或者拿到的“原始域名”不够准
        │
        ▼
这时进入 Sniffer（域名嗅探）
        │
        ├─ HTTP：看请求里的 Host
        ├─ TLS：看 ClientHello 里的 SNI
        └─ QUIC：看初始握手里可识别出的主机名信息
        │
        ▼
Sniffer 得到更接近真实目标的域名
例如：youtube.com
        │
        ▼
Mihomo 用这个域名继续做判断
        │
        ├─ 规则匹配
        │   DOMAIN-SUFFIX,youtube.com,PROXY
        │
        └─ 如开启 override-destination
            还可以直接把“实际访问目标”改成嗅探结果
        │
        ▼
最终决定：DIRECT / PROXY / REJECT / 指定策略组

总而言之，可以把域名嗅探理解成“补全目标信息”的过程：当 Mihomo 只看到 IP，或者现有目标信息不够准确时，它会再从连接内容里提取主机名，让后续分流尽可能按真实目标进行。

5. Tunnel配置 

tun:
  enable: true
  stack: system
  device: Ethernet99
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53
  strict-route: true
  mtu: 1500
  # 如果有使用zerotier或者headscale等，需要自己配置排除自己的网段
  # route-exclude-address: ["192.168.110.0/24"]

其中就我觉得只需要注意下 stack 这个参数即可

具体看我之前写的文章Tunnel三种模式的区别就可以了。结论如下：在确保能正常使用的前提下遵循这个顺序： system > mixed > gvisor

6. 节点配置 

# ## 订阅基础配置 [每天更新一次订阅节点，每 300 秒一次健康检查]
NodeParam: &NodeParam {type: http, interval: 86400, health-check: {enable: true, url: 'http://connectivitycheck.platform.hicloud.com/generate_204', interval: 300}}

# 订阅合集
proxy-providers:
  Node:
    url: 替换订阅链接
    <<: *NodeParam
    path: ./proxy_provider/providers.yaml

# 单节点(如果你是自建节点，那么请直接在下面的proxies里添加节点配置，具体节点写法请参考 mihomo 官方文档)
# proxies:
#   - {name: "示例节点", type: ss, server: example.com, port: 443, cipher: aes-256-gcm, password: "password", udp: true}

# 节点筛选
# 按地区筛选
FilterHK: &FilterHK '(🇭🇰|香港|[Hh][Kk]|Hong\s*Kong)'
FilterTW: &FilterTW '(🇹🇼|台[湾灣]|[Tt][Ww]|Taiwan)'
FilterUS: &FilterUS '(🇺🇸|美[国國]|America|United\s*States|[Uu][Ss])'
FilterJP: &FilterJP '(🇯🇵|日本|东京|大阪|[Jj][Pp]|Japan)'
FilterSG: &FilterSG '(🇸🇬|新加坡|狮城|[Ss][Gg]|Singapore)'

# ## 策略组基础配置
# 手动选择
Select: &Select {type: select, url: 'http://connectivitycheck.platform.hicloud.com/generate_204', disable-udp: false, hidden: false, include-all: true}
# 自动选择 [每 300 秒一次惰性健康检查，容差 50ms，时延超过 2 秒判定为失败，失败 3 次自动触发健康检查]
UrlTest: &UrlTest {type: url-test, url: 'http://connectivitycheck.platform.hicloud.com/generate_204', interval: 300, lazy: true, tolerance: 50, timeout: 2000, disable-udp: false, max-failed-times: 3, hidden: true, include-all: true}
# 自动回退 [每 300 秒一次惰性健康检查，时延超过 2 秒判定为失败，失败 3 次自动触发健康检查]
FallBack: &FallBack {type: fallback, url: 'http://connectivitycheck.platform.hicloud.com/generate_204', interval: 300, lazy: true, timeout: 2000, disable-udp: false, max-failed-times: 3, hidden: true, include-all: true}
# 负载均衡 [每 300 秒一次惰性健康检查，时延超过 2 秒判定为失败，失败 3 次则自动触发健康检查]
LoadBalance: &LoadBalance {type: load-balance, url: 'http://connectivitycheck.platform.hicloud.com/generate_204', interval: 300, lazy: true, disable-udp: false, strategy: consistent-hashing, timeout: 2000, max-failed-times: 3, hidden: true, include-all: true}

# 策略组
proxy-groups:
  # 主选择组
  - {name: 🎯节点选择, type: select, proxies: [智能选择, 手动选择, 全部节点, DIRECT], url: http://connectivitycheck.platform.hicloud.com/generate_204, icon: https://raw.githubusercontent.com/Orz-3/mini/master/Color/Static.png}

  # 手动/Auto
  - {name: 手动选择, type: select, proxies: [🇭🇰-手动选择, 🇯🇵-手动选择, 🇸🇬-手动选择, 🇺🇸-手动选择, 🇹🇼-手动选择], url: http://connectivitycheck.platform.hicloud.com/generate_204, icon: https://raw.githubusercontent.com/Orz-3/mini/master/Color/Cylink.png}
  - {name: 智能选择, type: select, proxies: [🇭🇰-Auto, 🇯🇵-Auto, 🇸🇬-Auto, 🇺🇸-Auto, 🇹🇼-Auto], url: http://connectivitycheck.platform.hicloud.com/generate_204, icon: https://raw.githubusercontent.com/Orz-3/mini/master/Color/Urltest.png}

  # 应用分组
  - {name: ✈️电报信息, type: select, proxies: [🎯节点选择, 🇭🇰-Auto, 🇯🇵-Auto, 🇸🇬-Auto, 🇺🇸-Auto], icon: https://raw.githubusercontent.com/Orz-3/mini/master/Color/Telegram.png}
  - {name: 🤖AIGC, type: select, proxies: [🇺🇸-Auto, 🎯节点选择, 🇭🇰-Auto, 🇯🇵-Auto, 🇸🇬-Auto], icon: https://raw.githubusercontent.com/Orz-3/mini/master/Color/OpenAI.png}
  - {name: 🍎苹果服务, type: select, proxies: [DIRECT, 🎯节点选择, 🇭🇰-Auto, 🇺🇸-Auto], icon: https://raw.githubusercontent.com/Orz-3/mini/master/Color/Apple.png}
  - {name: Ⓜ️微软服务, type: select, proxies: [DIRECT, 🎯节点选择, 🇭🇰-Auto, 🇺🇸-Auto], icon: https://raw.githubusercontent.com/Orz-3/mini/master/Color/Microsoft.png}

  # Auto
  - {name: 🇭🇰-Auto, type: select, proxies: [🇭🇰-自动选择, 🇭🇰-自动回退, 🇭🇰-负载均衡]}
  - {name: 🇯🇵-Auto, type: select, proxies: [🇯🇵-自动选择, 🇯🇵-自动回退, 🇯🇵-负载均衡]}
  - {name: 🇸🇬-Auto, type: select, proxies: [🇸🇬-自动选择, 🇸🇬-自动回退, 🇸🇬-负载均衡]}
  - {name: 🇺🇸-Auto, type: select, proxies: [🇺🇸-自动选择, 🇺🇸-自动回退, 🇺🇸-负载均衡]}
  - {name: 🇹🇼-Auto, type: select, proxies: [🇹🇼-自动选择, 🇹🇼-自动回退, 🇹🇼-负载均衡]}

  # 自动选择 - 按地区
  - {name: 🇭🇰-自动选择, <<: *UrlTest, filter: *FilterHK}
  - {name: 🇯🇵-自动选择, <<: *UrlTest, filter: *FilterJP}
  - {name: 🇸🇬-自动选择, <<: *UrlTest, filter: *FilterSG}
  - {name: 🇺🇸-自动选择, <<: *UrlTest, filter: *FilterUS}
  - {name: 🇹🇼-自动选择, <<: *UrlTest, filter: *FilterTW}

  # 自动回退 - 按地区
  - {name: 🇭🇰-自动回退, <<: *FallBack, filter: *FilterHK}
  - {name: 🇯🇵-自动回退, <<: *FallBack, filter: *FilterJP}
  - {name: 🇸🇬-自动回退, <<: *FallBack, filter: *FilterSG}
  - {name: 🇺🇸-自动回退, <<: *FallBack, filter: *FilterUS}
  - {name: 🇹🇼-自动回退, <<: *FallBack, filter: *FilterTW}

  # 负载均衡 - 按地区
  - {name: 🇭🇰-负载均衡, <<: *LoadBalance, filter: *FilterHK}
  - {name: 🇯🇵-负载均衡, <<: *LoadBalance, filter: *FilterJP}
  - {name: 🇸🇬-负载均衡, <<: *LoadBalance, filter: *FilterSG}
  - {name: 🇺🇸-负载均衡, <<: *LoadBalance, filter: *FilterUS}
  - {name: 🇹🇼-负载均衡, <<: *LoadBalance, filter: *FilterTW}

  # 手动选择 - 按地区
  - {name: 🇭🇰-手动选择, <<: *Select, filter: *FilterHK}
  - {name: 🇯🇵-手动选择, <<: *Select, filter: *FilterJP}
  - {name: 🇸🇬-手动选择, <<: *Select, filter: *FilterSG}
  - {name: 🇺🇸-手动选择, <<: *Select, filter: *FilterUS}
  - {name: 🇹🇼-手动选择, <<: *Select, filter: *FilterTW}

  - {name: 全部节点, <<: *Select}

这部分改动的地方就是订阅链接以及如果是自建节点，补充一下自建节点的信息即可，具体使用的协议可以查看Mihomo 出站代理进行补充信息。这边给大家一个建议，如果有能力部署/折腾Sub-Store的同学，欢迎使用该工具，能解决非常多订阅/单节点上的问题。

需要简单解释下 测试链接 最好不用直接用google的因为容易引起 Google 对 IP 的风控。

7. 重中之重 规则

首先，请注意，把所有非IP类规则写在 IP类规则之前，这是最没有问题的！前提你使用的模式跟我一样都是 fake-ip

避免 DNS 污染和 DNS 泄漏最有效的办法就是永远不在本地进行 DNS 解析，而 Mihomo 能且只能通过 Fake IP 和域名规则匹配的方式实现非直连域一定不在本地本机进行任何 DNS 解析。在 Mihomo 中，规则自上而下匹配，只有当遇到 IP 类规则（如 IP-CIDR、IP-CIDR6、GEOIP 和 IP-ASN）时才会发起 DNS 解析。因此，在 Mihomo 中，将会触发 DNS 解析的规则放在域名和 URL 匹配规则后面非常重要。[引用来自 sukka]

十分推荐大家先去看看 Sukka 的规则仓库以及文章再来写，会有不少收获。

# ## 规则配置
RuleSet_classical: &RuleSet_classical {type: http, behavior: classical, interval: 43200, format: text, proxy: 🎯节点选择}
RuleSet_domain: &RuleSet_domain {type: http, behavior: domain, interval: 43200, format: text, proxy: 🎯节点选择}
RuleSet_ipcidr: &RuleSet_ipcidr {type: http, behavior: ipcidr, interval: 43200, format: text, proxy: 🎯节点选择}

# 订阅规则
rule-providers:
  cdn_domainset:
    <<: *RuleSet_domain
    url: https://ruleset.skk.moe/Clash/domainset/cdn.txt
    path: ./rule_set/sukkaw_ruleset/cdn_domainset.txt

  cdn_non_ip:
    <<: *RuleSet_domain
    url: https://ruleset.skk.moe/Clash/non_ip/cdn.txt
    path: ./rule_set/sukkaw_ruleset/cdn_non_ip.txt

  stream_non_ip:
    <<: *RuleSet_classical
    url: https://ruleset.skk.moe/Clash/non_ip/stream.txt
    path: ./rule_set/sukkaw_ruleset/stream_non_ip.txt

  stream_ip:
    <<: *RuleSet_classical
    url: https://ruleset.skk.moe/Clash/ip/stream.txt
    path: ./rule_set/sukkaw_ruleset/stream_ip.txt

  ai_non_ip:
    <<: *RuleSet_classical
    url: https://ruleset.skk.moe/Clash/non_ip/ai.txt
    path: ./rule_set/sukkaw_ruleset/ai_non_ip.txt

  telegram_non_ip:
    <<: *RuleSet_classical
    url: https://ruleset.skk.moe/Clash/non_ip/telegram.txt
    path: ./rule_set/sukkaw_ruleset/telegram_non_ip.txt

  telegram_ip:
    <<: *RuleSet_classical
    url: https://ruleset.skk.moe/Clash/ip/telegram.txt
    path: ./rule_set/sukkaw_ruleset/telegram_ip.txt

  apple_cdn:
    <<: *RuleSet_domain
    url: https://ruleset.skk.moe/Clash/domainset/apple_cdn.txt
    path: ./rule_set/sukkaw_ruleset/apple_cdn.txt

  apple_services:
    <<: *RuleSet_classical
    url: https://ruleset.skk.moe/Clash/non_ip/apple_services.txt
    path: ./rule_set/sukkaw_ruleset/apple_services.txt

  apple_cn_non_ip:
    <<: *RuleSet_classical
    url: https://ruleset.skk.moe/Clash/non_ip/apple_cn.txt
    path: ./rule_set/sukkaw_ruleset/apple_cn_non_ip.txt

  microsoft_cdn_non_ip:
    <<: *RuleSet_classical
    url: https://ruleset.skk.moe/Clash/non_ip/microsoft_cdn.txt
    path: ./rule_set/sukkaw_ruleset/microsoft_cdn_non_ip.txt

  microsoft_non_ip:
    <<: *RuleSet_classical
    url: https://ruleset.skk.moe/Clash/non_ip/microsoft.txt
    path: ./rule_set/sukkaw_ruleset/microsoft_non_ip.txt

  download_domainset:
    <<: *RuleSet_domain
    url: https://ruleset.skk.moe/Clash/domainset/download.txt
    path: ./rule_set/sukkaw_ruleset/download_domainset.txt

  download_non_ip:
    <<: *RuleSet_domain
    url: https://ruleset.skk.moe/Clash/non_ip/download.txt
    path: ./rule_set/sukkaw_ruleset/download_non_ip.txt

  lan_non_ip:
    <<: *RuleSet_classical
    url: https://ruleset.skk.moe/Clash/non_ip/lan.txt
    path: ./rule_set/sukkaw_ruleset/lan_non_ip.txt

  lan_ip:
    <<: *RuleSet_classical
    url: https://ruleset.skk.moe/Clash/ip/lan.txt
    path: ./rule_set/sukkaw_ruleset/lan_ip.txt

  domestic_non_ip:
    <<: *RuleSet_classical
    url: https://ruleset.skk.moe/Clash/non_ip/domestic.txt
    path: ./rule_set/sukkaw_ruleset/domestic_non_ip.txt

  direct_non_ip:
    <<: *RuleSet_classical
    url: https://ruleset.skk.moe/Clash/non_ip/direct.txt
    path: ./rule_set/sukkaw_ruleset/direct_non_ip.txt

  global_non_ip:
    <<: *RuleSet_classical
    url: https://ruleset.skk.moe/Clash/non_ip/global.txt
    path: ./rule_set/sukkaw_ruleset/global_non_ip.txt

  domestic_ip:
    <<: *RuleSet_classical
    url: https://ruleset.skk.moe/Clash/ip/domestic.txt
    path: ./rule_set/sukkaw_ruleset/domestic_ip.txt

  china_ip:
    <<: *RuleSet_ipcidr
    url: https://ruleset.skk.moe/Clash/ip/china_ip.txt
    path: ./rule_set/sukkaw_ruleset/china_ip.txt

# 分流规则
rules:
  # ## 非 IP 类规则
  - RULE-SET,cdn_domainset,🎯节点选择
  - RULE-SET,cdn_non_ip,🎯节点选择
  - RULE-SET,stream_non_ip,🇺🇸-自动选择
  - RULE-SET,telegram_non_ip,✈️电报信息
  - RULE-SET,apple_cdn,DIRECT
  - RULE-SET,download_domainset,🎯节点选择
  - RULE-SET,download_non_ip,🎯节点选择
  - RULE-SET,microsoft_cdn_non_ip,DIRECT
  - RULE-SET,apple_cn_non_ip,DIRECT
  - RULE-SET,apple_services,🍎苹果服务
  - RULE-SET,microsoft_non_ip,Ⓜ️微软服务
  - RULE-SET,ai_non_ip,🤖AIGC
  - RULE-SET,global_non_ip,🎯节点选择
  - RULE-SET,domestic_non_ip,DIRECT
  - RULE-SET,direct_non_ip,DIRECT
  - RULE-SET,lan_non_ip,DIRECT

  # ## IP 类规则
  - RULE-SET,telegram_ip,✈️电报信息
  - RULE-SET,stream_ip,🇺🇸-自动选择
  - RULE-SET,lan_ip,DIRECT
  - RULE-SET,domestic_ip,DIRECT
  - RULE-SET,china_ip,DIRECT
  - MATCH,🎯节点选择

8. 仓库及推荐

仓库：自己目前在用且持续更新的配置仓库 selfproxy 欢迎各位同学帮忙点个star🌟，访问后点击进入Mihomo目录即可。

机场推荐（AFF）：FlowerCloud，花云是我用的很久的一家机场了，一线机场里算性价比拉满的一家，大家可以按需订购。

9. 参考

Sukka

Rabbit-Spec

metacubex

10. 可视化客户端

  1. clash-party 我自己Windows端本来使用的是裸核，不过近期也是换成mihomoparty了 推荐大家使用下（最近party可能发生了一些事情，貌似不再维护更新了） party我有参与过PR
  2. sparkle Party 的分支版本，由于Party发生了一些事情，现在只在这个分支进行更新，更推荐大家用这个版本
  3. clash-verge-rev verge-rev 也很不错 我也有参与verge-rev的PR
  4. FlClash 如果想一劳永逸，不怎么折腾客户端的话，更推荐 FlClash。

客户端使用请结合一下我的这篇文章 Mihomo Party 覆写/Clash Verge Rev 扩展脚本，能帮助大家更快上手。

覆写仓库在这里！

建议：有能力还是裸核+external-ui吧！

11. 交流

TG： Channel

Comments
> cd ..
CC BY-NC-SA 4.0 2020-PRESENT © yyhhyyyyyy