01 策略组高级用法
策略组决定了一组节点该如何被自动或手动选择,选对类型能显著提升日常使用的稳定性。
| 类型 | 行为 | 适用场景 |
|---|---|---|
| select | 完全手动选择,不自动切换。 | 需要长期固定使用某个节点,或手动控制线路时。 |
| url-test | 定期测速,自动切换到延迟最低的节点。 | 日常使用的首选,无需手动干预即可获得较优线路。 |
| fallback | 按顺序尝试节点,当前节点失效才切换到下一个。 | 希望优先使用某个主力节点,仅在故障时才切换的场景。 |
| load-balance | 在多个节点间分摊连接,而非只用一个。 | 多节点带宽有限、希望合并带宽或分散压力时。 |
| relay | 按顺序串联多个节点,流量依次经过每一跳。 | 需要多级跳转以提升匿名性或绕过特定限制的场景,速度会下降。 |
# 组合用法示例:外层用 select 手动切换地区,内层用 url-test 自动选优
proxy-groups:
- name: "PROXY"
type: select
proxies: ["HK-AUTO", "SG-AUTO", "JP-AUTO"]
- name: "HK-AUTO"
type: url-test
proxies: ["HK-01", "HK-02"]
url: "http://www.gstatic.com/generate_204"
interval: 300提示:策略组可以互相嵌套引用(如上例),这是构建"手动选地区 + 自动选优节点"两层结构的常见写法。全部字段说明见配置文档 proxy-groups 字段。
02 TUN 模式详解与配置
TUN 模式在系统网络层创建一张虚拟网卡,接管设备上几乎全部的网络流量,相比系统代理模式兼容性更好——尤其是对不遵循系统代理设置的游戏、部分客户端软件而言。
# 开启 TUN 模式的最小配置
tun:
enable: true
stack: gvisor
auto-route: true
auto-detect-interface: true
# TUN 模式推荐搭配 Fake-IP 一起开启
dns:
enable: true
enhanced-mode: fake-ip不同系统的授权方式
| 系统 | 授权方式 |
|---|---|
| Windows | 以管理员身份运行客户端,首次开启会自动安装 TUN/TAP 驱动。 |
| macOS | 首次开启会请求安装网络扩展或 VPN 配置,在系统设置中确认允许。 |
| Android / iOS | 系统会弹出 VPN 连接授权提示,需要手动点击允许。 |
| Linux | 需要以 root 权限运行,或为二进制文件配置 CAP_NET_ADMIN 权限。 |
提示:开启 TUN 模式后如果无法上网,先确认
auto-route 与 auto-detect-interface 均已开启;如果依然异常,可尝试将 stack 从 gvisor 切换为 system 排查是否为协议栈兼容性问题。03 Fake-IP 与 DNS 进阶配置
Fake-IP 让内核在 DNS 解析阶段返回一个虚构的本地地址,实际的连接目标判断被推迟到流量经过内核时才处理,这样域名匹配类规则(DOMAIN-SUFFIX 等)能更准确地生效,也是 TUN 模式下推荐的搭配方式。
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "localhost.ptlogin2.qq.com"
nameserver:
- 223.5.5.5
- 119.29.29.29
fallback:
- tls://1.1.1.1:853
- tls://8.8.8.8:853字段说明
| 字段 | 说明 |
|---|---|
| fake-ip-range | Fake-IP 使用的虚拟地址段,通常使用私有网段,避免与真实局域网地址冲突。 |
| fake-ip-filter | 不使用 Fake-IP 的域名白名单,局域网设备、登录鉴权等场景常需要排除。 |
| nameserver | 常规解析使用的上游 DNS,国内地址建议使用国内解析节点。 |
| fallback | 当 nameserver 的解析结果被判定为污染(如返回的 IP 不在预期地区)时,使用的备用加密 DNS。 |
提示:局域网内的路由器管理页面、部分需要局域网直连的登录鉴权服务,建议加入
fake-ip-filter,避免被错误代理导致无法访问。04 Rule Provider 规则集进阶用法
规则集把大量规则集中维护在远程文件中,客户端定期拉取更新,避免手动逐条编写与维护。搭配多个不同 behavior 的规则集,可以构建一套完整、可持续更新的分流方案。
rule-providers:
direct-domain:
type: http
behavior: domain
url: "https://example.com/direct-domain.txt"
path: ./ruleset/direct-domain.yaml
interval: 86400
private-ip:
type: http
behavior: ipcidr
url: "https://example.com/private-ip.txt"
path: ./ruleset/private-ip.yaml
interval: 86400
rules:
- RULE-SET,private-ip,DIRECT
- RULE-SET,direct-domain,DIRECT
- MATCH,PROXY提示:更新周期(
interval)不建议设置过短,规则集通常不会频繁变化,过于频繁的拉取只会增加不必要的网络请求。详细选型建议见博客文章《Rule Provider 规则集完全指南》。05 性能与稳定性优化建议
1
精简规则列表规则条数越多,每次匹配的开销越大;把低频使用的规则合并进规则集,保留少量高频自定义规则在本地列表即可。
2
合理设置测速间隔url-test 的 interval 过短会增加额外流量与 CPU 占用,过长又会导致节点异常后切换不及时,300~600 秒是较均衡的区间。
3
避免不必要的多级串联relay 类型的多级节点串联会显著增加延迟,仅在确有必要(如需要多重跳转)时使用。
4
按需开启日志级别日常使用建议将 log-level 设置为 warning 或 error,排查问题时再临时切换到 debug,避免长期产生大量日志文件。
5
定期检查内核与客户端版本新版本通常包含性能优化与协议兼容性修复,建议定期前往下载页核对是否有更新。