分母+1

@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 才行。

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

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

不知道其有没有影响。

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

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

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

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

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

@jsq2627 #14 这个代码中有检查 port: targetAddr.Port() == 53 ，并且经过测试(clashxpro 的测试) `dig @198.18.0.2 baidu.com -p 12345` 是没有结果的。所以应该是有一点错误的。

@FaiChou #22 并且没有选用 198.18.0.1 的原因在 10 楼已经给出答案了。如果其他程序 bind 了所有网口 53 端口，那么会冲突。

@wdf1286 并不赞同，可以看到 append 中的例子，是可以绑定 192.18.0.1 并且正常收到请求的。" clash 注册的那个 tun 设备"的 ip 地址就是 198.18.0.1 ，和 127.0.0.1 还有 192.168.11.109 （我的电脑）等都是网口的地址，198.18.0.1 是 utun 的网口地址，127.0.0.1 是 lo0 ，192.168.11.109 是 en0 的。如果程序监听 0.0.0.0 ，则向前面这三个网口的地址发起请求都可以正常收到。

@jsq2627 #13 谢谢。执行 route -n get ip 时候确实漏掉了一些关键信息，比如 198.18.0.2 的 flag 其中有 H, 说明是个 HOST 点对点的地址，不需要经过路由。所以冒昧再问一个问题，这个 198.18.0.2 在哪里被添加成 HOST 的？难道在 dnsAdds 的 ListenerHandler 处理的吗？如果是一个普通的监听服务器，如果 198.18.0.2 没有对应的网口则监听失败，和我 append 中的情况一样。所以这一块核心在哪里？找了一会没有找到。

@jsq2627 #8
"198.18.0.2 走的也是 128.0/1 这条路由，被当成普通流量送往了 utun10"
第一：使用 `route -n get 198.18.0.2` 的结果为什么和 198.18.0.4 有差别呢？

第二：我搜了下 clash-meta 的源码，没有找到 `198.18.0.2` 的关键字，clashxpro 和 surge 没有开源，所以也看不到具体的实现。所以 "检查到 dst ip 是 198.18.0.2 之后，认为这是一个 dns 请求" 可能是这样的，但并不能确定。

另外，谢谢回复。

我写了一个程序来测试:

```
const http = require('http');
const server = http.createServer((req, res) => {
res.setHeader('Access-Control-Allow-Origin', '*');
res.setHeader('Content-Type', 'text/plain');
res.end('Hello');
});
const ifrq = "198.18.0.2";
server.listen(3000, ifrq, () => {
console.log(`Server running at http://${ifrq}:3000/`);
});
```

开启增强模式后 如果 ifrq 是 198.18.0.1 则可以正常绑定到这个地址，打开这个地址 3000 端口后正常响应。
但如果将 ifrq 改成 198.18.0.2 ，则服务起不了 Error: listen EADDRNOTAVAIL: address not available 198.18.0.2:3000

@Darin726 为什么不是 198.18.0.1 而是 0.2 ? 通过 dig 命令可以测试到 198.18.0.1 也是可以响应 dns 请求的（ listen: 0.0.0.0:53 起作用）。为什么要用 0.2 这个子网？

@imnpc 对，故意没有说这几个单词的，容易触发关键字，被移动到某节点下，不会出现在首页。