RPRX

~~我觉得你们说的都有些道理~~ 一般来说我们不喜欢加机场专属功能，比如限 IP、限速，虽然 @FranzKafkaYu 找了一个不错的理由，~~不过我们都心知肚明~~ 总之如果这是个 Feature Request，我肯定是不会去实现的，如果这是个写好的 PR，可以考虑一下，~~毕竟你们都找了“正当”理由~~

> If they shared,you should kick them out. ~~这也是我想说的~~

@amir-devman 我看了下代码和配置方式，把它移到 `policy` `levels` 更合适，字段名为 `maxIPs`

> Please take into consideration that the IPs on behind of CDN should be selected by X-REAL-IP header or other headers WebSocket 入站有自动处理，gRPC 不清楚，麻烦 @amir-devman 测试一下

第 190 行，可能是上面的 `req, _ = http.NewRequest("GET", firstURL, nil)` 或 `req, _ = http.NewRequest("GET", string(prefix)+getPathLocked(paths), nil)` 返回了 error，不过当初我本地测试是没问题的。 认证失败时才会触发这部分代码，应该有不少人触发过，第一次收到 panic 报告。 --- 目标网站/域名的选择会极大程度地影响 REALITY 代理的延迟、速度、稳定性等： 1. 至少目前，REALITY 每次都要去拿握手包，需要注意目标网站近不近、稳不稳定（请求多了就把你半拉黑也是一种不稳定）。 2. 运营商层面可能会给某些域名更高的流量优先级，拥堵时优先保证它们的流量通过。...

~~也可能是你们天天逮着 microsoft、apple 之类的偷，GFW 开始测试了~~，有人说伊朗那边就有运营商在“内测” yahoo 的 IP 白名单。 --- REALITY 以后会出个缓存模式，提前采集目标网站的特征，就不用每次都去拿了，这也是相对于 ShadowTLS 之类的优势之一。 还有就是 REALITY 隐藏玩法的任意 SNI、无 SNI，对 REALITY 来说，只要服务端 serverNames 写了，客户端 serverName 就能填。 我需要说明一下不是只有 1.1.1.1 和 8.8.8.8，而是绝大多数网站都有“默认证书”。不过不希望这个玩法泛滥，因为特征明显。

To tinyflag east：“只要 serverName 是 serverNames 之一”的意思是只要服务端写了，客户端就能填，不需要 dest 真的有那个网站 SNI 分流与“REALITY 对外表现为端口转发”的目标不符，REALITY 服务端的实现非常严谨，对任何非认证流量都是纯端口转发 本质上，REALITY 是一开始就双向转发，同时在旁路尝试对双向流量进行条件非常严格的认证，~~这句话我好像在哪说过~~

> 我问chatgpt哪些是有 https://ip 的网站回答的是1.1.1.1 8.8.8.8 9.9.9.9我试了不通。还能有其它的？有空研究下了。 显然是误解了 https://t.me/projectXtls/78 ，一般来说 TLS 服务端都有个“默认证书”，除非配置了拒绝未知 SNI 之类的 [RealiTLScanner](https://github.com/XTLS/RealiTLScanner) 就是用这个原理来扫 IP 段的网站的，~~换句话说它扫出来的网站都可以无 SNI，极大概率也能任意 SNI~~

To 群里：对于喜欢用已经黑了的 IP/IP 段测试 REALITY 的，我只能说，

~~建议拉满，以后只用甲骨文~~