clash 中将使用 url-test 的节点进行 relay 放到 fallback-auto 中的奇怪问题

[FaiChou]

有一个自建的日本服务器，但是直接访问这个日本服务器会比较慢。 于是想到了用一个机场的 url-test 进行 relay ，将机场中的所有日本节点使用正则将其放到一个 group 中，这个 group 用 url-test ，每 6 分钟进行一次测试，它会自动选择延迟最低的节点，这样用这个节点 relay 日本服务器，生成一个新的 group 。这样的一个节点大概率是可用的，最终落地 ip 也是稳定的。

但有些情况，比如日本服务器维护了，或者机场的节点都挂了，这样上面这个节点就会不可用。

所以将其放到 fallback-auto 中，它会自动选取第一个可以连接的节点，也是每 6 分钟检测一次。

但经过最近一段时间的测试(openwrt 每天晚上自动重启+openclash meta 内核)，fallbackauto 组经常不会选择第一个 relay 节点，需要手动先对日本节点测试，再在 fallbackauto 组测试后，才会选择上第一个节点。

所以不知道是软件问题还是我配置问题。 能想到的问题应该可能跟 url-test 的测试频率有关系。如果 url-test 没有进行测试，此时选择的第一个节点如果不可达，这时 fallback 测试，会用第一个日本节点进行 relay ，使用正则进行选取的日本节点无法手动排序。

讲了这么多不知道讲清楚没有，下面是配置：

- { name: fallback-auto, type: fallback, use: [], proxies: [Relay, 自建服务器, 日本, 香港, 新加坡, 美国, 其他], url: 'http://www.gstatic.com/generate_204', interval: 300 }
- { name: Relay, type: relay, proxies: [日本, 自建服务器] }
- { name: 日本, type: url-test, filter: "(?i)日|🇯🇵|JP|jp|(?i)japan", use: [机场 1, 机场 2, 机场 3], url: http://cp.cloudflare.com/generate_204, interval: 600 }

经过测试:

- { name: 机场测试, type: url-test, use: [机场], proxies: [], url: http://www.gstatic.com/generate_204, interval: 120, lazy: false }

这样针对机场的 url-test 不生效。

只能在 proxy-providers: 中对机场打开 health-check 才行。

总结一下 clash 规则里的坑

默认 lazy: true，不管是 group 里的还是 proxy-provider health-check 里，所以有可能

如果用一个 proxy-provider 作为一个 group，那么进行 url-test 是不起作用的, 比如下面例子:

proxy-providers:
  provider1:
    type: http
    url: "url"
    interval: 3600
    path: ./provider1.yaml
    health-check:
      enable: true
      interval: 600
      url: https://cp.cloudflare.com/generate_204

proxy-groups:
  - name: "auto"
    type: url-test
    use:
      - provider1
    proxies:
      - ss1
      - ss2
      - vmess1
    url: "https://cp.cloudflare.com/generate_204"
    interval: 300

上面 auto 组中，只有 ss1 ss2 和 vmess1 这些节点会 300 秒进行一次测速，而 provider1 不会进行测速，即使它的 health-check 是 enbale 的，由于默认是 lazy: true，只有当有节点选择它时候才会触发测速。如果整个 auto 组都没有被使用，ss1, ss2, vmess1 都不会被测速。所以想使其自动测速，需要手动加上 lazy: false。

[FaiChou]

fallback-auto 进行 test 时候 会触发 url-test 吗？

[ncepuzs]

配置文件看上去没啥问题，不过 url-test 这类规则在内核重启或更新订阅时确实会先默认使用组内第一个节点

只是，我有个疑问，为什么要执着使用机场的日本节点来 relay 呢，其他地区效果也一样啊；以及，用作 relay 的话，负载均衡 consistent-hashing 甚至是 round-robin 应该要比单一 url-test 要好啊。这样的话，可能也就不需要 fallback 分组了

[FaiChou]

@ncepuzs 我的服务器在日本，日常直连测试延迟 500+ms ，使用机场的日本节点 relay 是 400 左右。使用 relay 不怕自建的服务器被墙，并且最终请求都是从自建服务器发出的，ip 也不会随便乱动。

load balance 的话不论是轮询还是散列 eTLD+1 ，都是更换一堆节点访问。
比如我打开 PayPal 网站，可能用的节点 A ，关掉页面（ tcp 连接断开）下次再访问，节点就换了。这样不稳定不符合我的要求。

[FaiChou]

@ncepuzs 有没有跟正则有关系？正则后的列表 url-test 问题。我开了一会 clashxpro ，记得之前 url-test 会保留一堆测速结果，当我去看时候并没有测速。

[totoro625]

1 、设置 lazy: false
Meta issue 较少，但是因为是 Another Clash Kernel ，可以参考 clash： https://github.com/Dreamacro/clash/issues/2809
2 、interval 不要设置倍数关系
可能测速结果丢了，或者测速时间太长，被 fallback 跳过了
3 、日本组内设置节点少于 10 个试试

[totoro625]

@FaiChou #3 指的是让你 relay 里面的“日本, type: url-test”换成“load-balance round-robin”，这样一堆日本的节点连接 relay ，最终请求都是从自建服务器发出的，ip 不会随便乱动。

[FaiChou]

@totoro625 那如果从某个延迟很高的节点发出 relay ，比直连更慢了。所以主题中的方案应该是最佳了。

[ncepuzs]

@FaiChou 不是，我是说你“日本”这个分组使用 type: load-balance 或 url-test 所有节点，既然是 relay 为什么不用最快的或者是尽可能榨干线路呢

[FaiChou]

@totoro625 #5
查看 ClashX Pro 的日志，使用正则匹配的 group 进行 url-test 都会失败: HeathCheck for 日本 failed:404 。虽然日志显示失败，但最终是没问题的。

不知道其有没有影响。

[totoro625]

@FaiChou #9 自建落地，有条件的话，在自己的 vps 上放 generate_204 或者一个小文件用于 urltest
这样速度才是到你的 relay 节点最快的，而不是到测速节点最快的
鉴于你没提你的机场是哪一家，部分无良机场会劫持 generate_204 到入口，可以考虑放点别的到 urltest ，如一个 ok.html

[FaiChou]

@totoro625 #10 绿云。。黑 5 买的三年 现在线路贼拉胯

[FaiChou]

@totoro625 #5

经过测试:

- { name: 机场测试, type: url-test, use: [机场], proxies: [], url: http://www.gstatic.com/generate_204, interval: 120, lazy: false }


这样针对机场的 url-test 不生效。

只能在 proxy-providers 中对机场打开 health-check 才行。