RPRX
@yuhan6665 这里可能是没给另一边 counter 加，我们把它和 https://github.com/XTLS/Xray-core/issues/3058 修了后发 v1.8.9 吧，等下我更新下分享链接标准
@yuhan6665 https://github.com/XTLS/Xray-core/discussions/716 已更新。你修一下这个 issue 和 https://github.com/XTLS/Xray-core/issues/3058 （启动时跑一下检测就行），我修一下 https://github.com/XTLS/Xray-core/issues/2248 和 https://github.com/XTLS/Xray-core/issues/3101
> 观察 xray 的输出日志，可以发现源IP固定为第一次连接的客户端IP，不会随客户端网络切换发生变化。 按理来说客户端切换网络后 TCP 会断，会开一条新的 TCP，~~请再测几次确定该问题确实存在~~
~~反直觉，先关了~~
如果问题存在的话，只有一种可能，就是 Caddy 复用了到 Xray 服务端的连接，~~但这样会导致所有用户都成了同一个 IP 吧~~
根据去年的众多报告，GFW 对 Shadowsocks 可以做到秒封，而对 Trojan 一般是隔天封端口，猜测是因为 SS 几条连接就可以实锤，而封锁 Trojan 时 GFW 需要收集更多的连接数据、辅以多个维度的信息来~~加权求和~~，也就是说封锁这两类适用于不同的决策机制
> > trojanUpUB 在 Trojan-killer 中目前是 [750](https://github.com/XTLS/Trojan-killer/blob/02c3683d1e1dba7a4f91462c7831f5caec0e15fc/main.go#L72)，而在 OpenGFW 中是 1000，应该会增加误报率，这是为了匹配内层 ECH 吗 > > 是的，我测试的时候发现 750 会匹配不到浏览器发起的很多连接（curl 之类的倒是没问题），必须改到 1000 才行。原因就是 ECH 和一些乱七八糟的额外 extensions 去年 Trojan-killer 放出的时候（2023 年 5 月）~~好像还没这么乱~~，去年底我测试 ECH...
看了下去年底测试 ECH 的 pcapng 文件，Chrome CH 长度均未超过 600，为了匹配它加 100 是可以接受的，即 650~850
> > 不过它们至今仍要手动开 flag > > [TLS Encrypted Client Hello (ECH)](https://chromestatus.com/feature/6196703843581952) 特性已在 Chromium 117 版本后默认启用，而 [X25519Kyber768 key encapsulation for TLS](https://chromestatus.com/feature/5257822742249472) 特性计划至 124 版本后才默认启用，124 稳定版本计划在 4 月 10 日发布。 感谢，我用 Chrome...
~~看起来 Trojan-killer 需要更新 2.0 了~~，虽然增大匹配范围必定会增大单个连接的假阳率，但配合“封锁算法”应该仍能做到足够精准