可以，2 台 AMD 免费，一台 2c 24G 的 ARM 免费。每个月 10T 流量。但有时候资源有限。升级只是确保开出的概率大一些而已。

@vx007 你说的这些方法以及规则的写法都用过，并且最开始的认知和判断和你上面给出的说法是一样的。但 实际用下来，类似于"geosite:!cn" 并不能保证某个原本境外域名一定会被判定为境外，因为这只是一个库且需要不断更新的库，别人维护的规则总有更新不及时或者不准确（或者说不符合你要求）的时候， 你的两种写法，第一种的遇到的典型问题：一个实际 loacation 在 cn 的域名，不在 geosite:cn 里，导致查询缓慢或者出错。第二种写法：geosite:!cn （包括还有一种写法叫 geolocation ）类似，一个原本就希望在远端 VPS 上进行解析的域名，还要先在本地做一次远端 dns 解析（效率问题），而且还可能因为 dat 文件的原因导致 nameserver-policy 判断不准确导致用阿里云去做 DNS （泄露及准确度问题）。

就这样吧，就说这么多。你觉得没泄露，那就没泄露呗。

@dford 看我前一条 replay 。

这是一条 ip 规则，比如你要访问的一个请求是 https：//www.xxx.org/xxxx 如果没有 no-resolve ，那么在没有命中上面的其他规则的的情况下走到这里，就会触发一次本地的 DNS 解析，这里就会泄露。

只有 2 种情况是要进行本地 DNS 解析：
1. 命中了一条 IP 规则，那么要解析域名判断是否命中规则
2. 确定要走直连，最终进行域名解析得到 IP 建立连接

事实上实践中应该尽量避免减少本地 DNS 解析，这不仅可以加快网路的访问速度和效率，而且可以避免泄露，尤其是其中 1 的情况，所以正确的做法是在所有 IP 规则最后都应该加上 no-resolve ，包括 GEOIP,CN,DIRECT 这一条，即： - GEOIP,CN,DIRECT,no-resolve

这种情况下，需要去远端的就去远端进行 DNS 解析了，也就不存在泄露，不需要去远端的（直连）反正你也不在乎泄露不泄露，用阿里云解析得到 ip 后直连即可。

也可以 这样

handle @foo {
handle_path /api/* {
reverse_proxy localhost:8080
}

handle {
reverse_proxy localhost:9080
}
}

知道了 直接全部在 handle 里处理，类似这样

handle @bitwarden {
encode gzip
reverse_proxy /notifications/hub/negotiate nas:7777
reverse_proxy /notifications/hub nas:3012
reverse_proxy nas:7777
}

如果我对某个域名还要处理 handle_path

怎么写？

比如

handle_path /xyz/* {
reverse_proxy xyz:9527
}

@gniviliving 联通现在还有 50ms 的延迟么 为啥我新开的 都 200 多。线路还绕路~

就是告诉你 3 个错误的原因 abc

FreshRSS+RssHub

玄学，我同一个卡和信息 ，同样的信息之前注册了十多次都是 abc 失败，最近一次成功了。