RPRX
还有既然已经引入了探测机制，那么 REALITY README 写的“预先构建模式”，即提前采集目标网站特征、不用每次都 call target，以及这个也可以提上日程了：https://github.com/XTLS/REALITY/blob/90e738a94c8ca934d61932afe471712197a3dd36/tls.go#L321
https://github.com/XTLS/Xray-core/issues/4778#issuecomment-2952490470
https://github.com/XTLS/Xray-core/issues/4778#issuecomment-2996196290
https://github.com/XTLS/Xray-core/issues/4778#issuecomment-3072047745
https://github.com/XTLS/Xray-core/issues/4778#issuecomment-3091241760
https://github.com/XTLS/Xray-core/pull/3832 > And somehow the browser dialer of SplitHTTP is implemented via WebSocket instead of `fetch` request in either direction. 关于这个我想起来了，因为初版 browser dialer 写于 2021 年，而 chromium 在 2022 年才支持...
~~刚又仔细看了一眼发现自己已读乱回了~~
> Chrome [uses QUIC "connection migration"](https://lists.wireshark.org/archives/wireshark-users/202407/msg00004.html) which is basically a connection teardown and resumption using another source port and without handshake, so the DPI can't detect SNI in it. 说起来，中国并没有封死...
可以，但起作用的点在于搭了个 proxy，如果这个 proxy 是公开的则迟早会被封 即使是私有的，Chrome 的 DoH 具有类似 TLS in TLS 那样相对固定的长度特征，ODoH 应该也无法幸免，GFW 可以分析大量数据后认为该服务器在提供 DoH/ODoH 服务并封锁它，解决办法是加 padding，比如 Xray 前几天给 DoH request 的 header 加了 padding：https://github.com/XTLS/Xray-core/commit/e466b0497c3c563622146e2595d4870e4a43f56e#diff-70be69743619b578d48e9a299311b5fde596a003f7a65668d01c05a2a9ac2eafR284 当时有这个 commit 是因为我认为 GFW 会干扰境外公共...
它这个填充应该不是 request header 吧，也就是说 DoH 有可供填充的结构？我还没研究 *It's not a request header, is it? In other words, DoH has a structure that can be filled in? I haven't researched it yet.*