RPRX
我误解了你，你也误解了我，我本来以为你那个 `priorIPs` 是填 "0.0.0.0/0" 和 "::/0" 用的，作为第二层 expected 但是这个误解正好导致一个更简洁而强大的想法：把 `expectedIPs` 改为逐级匹配的，这一点你还没看懂 https://github.com/XTLS/Xray-core/pull/4666#issuecomment-2843772399 至于如何合并反选，我还得再想想
我觉得四个选项叠一起的话逻辑有点混乱，压成两个选项就行，`unexpectedIPs` 是可以加的，它们是合并而不是逐级，且作用于 `expectedIPs` 每一级匹配成功之后（除非 "0.0.0.0/0 或 "::/0"），比如第一级匹配到了但被 `unexpectedIPs` 否决了就继续下一级
这样就可以 cover 所有需求了，更少的配置项，更强大的功能
比如如下配置 ```json "expectedIPs": ["geoip:us", "geoip:uk", "0.0.0.0/0", "::/0"], "unexpectedIPs": ["10.10.34.0/24", "2001:4188:2:600:10:10:34:0/120"] ``` 逻辑是 1. expect US IPs, if we picked an IP, check all `unexpectedIPs`, if no IP was picked or...
这并不会严重破坏 `expectedIPs` 的行为，只是把 US 放第一级、UK 放第二级了，这可以接受，用户配置里本来就是这个顺序，我不确定现有的代码逻辑里是合并了还是逐级匹配，但是改成逐级匹配没有难度，就只是改成 for 循环，比多两个选项要简单 并且如果有人要 third 或者更多，他也可以通过优先级顺序来实现
简单来说就是你的 PR 在广义范围上的 expected 功能只有两级且第二级只能全选，我提的是 expected 多级且每级范围可以自定义
> and don't change the current `expectedIPs" behavior 这个可以 change 啊，有什么问题吗，可以实现把更细分的 IP 范围放前面以优先匹配，比如 CF、US、ALL
只有 stream-one 可能可以 *Only stream-one may be possible*
> 我的观点：千万不要再加 log type 了 下次把 DNS log 类型也可以删掉 > access log 可以加入更多信息 尽量不要开关选项 多一点日志不是大问题 赞同，~~毕竟 Go 写的软件就该大道至简~~
> my (really shaky) understanding of the ALPN logic is: > > 1. if it is websocket, the ALPN is always h1 > > 2. if it is set via...