RPRX

这样的话以后 Xray 也给 DoH body 本身加个随机 padding 吧，不过 Golang 应该是默认把 request header 和确定的 body 粘了起来 现在更加重要的事情是给 Xray 加个自建 DoH server with padding 的功能，并且禁止不带 padding 的请求 至于 Chrome 没给 DoH 加...

> In fact, this solution is used to resolve the problem that Cloudflare DNS has been blocked in China recently. 如果要以非自建 proxy server 的形式解决 DoH 被封的问题，则可能只有 domain fronting 这一条路，比如找到个可用 IP，SNI...

> ODoH or OHTTP is not TLS in TLS. Plain DoH in TLS / Plain ODoH in TLS / Plain DoH in OHTTP in TLS

我第一句评论就是： “可以，但起作用的点在于搭了个 proxy，如果这个 proxy 是公开的则迟早会被封” 而 domain fronting 是在 GFW 把 SNI 封了之后仍然能访问 DoH 的东西 *My first comment was:* *“Yes, but the point is that a proxy is used, and...

原描述有歧义，我修改了描述为 "Plain DoH in TLS / Plain ODoH in TLS / Plain DoH in OHTTP in TLS" 就像 TLS handshake 有相对固定的长度特征，DoH / ODoH 请求与响应本身也有相对固定的长度特征，你可以用 WireShark 观察到 *The original description was...

> I afraid that CDN/cloud servers which support domain fronting will become less an less. 对于 DoH 来说，几乎只要有可用的就行，而你总能找到一个能够域前置的 DoH，~~实在不行就自己建一个~~ 还有 ECH 能暂时解决问题，但它们用的固定 SNI 在未来也可能会被封 *For DoH, almost anything that is...

@0x391F You are able to reopen the issue as it was closed by yourself.

这就是我的意思，ODoH / OHTTP 对于“绕过封锁”这个目标只是起到了“代理”的作用，并且公开的“代理”迟早会被封锁 我认为最佳的绕过 DoH 封锁的方式是 domain fronting + padding，因为你总能找到允许域前置的服务商 *This is what I mean. ODoH/ODHTTP only serves as a “proxy” for the goal of “bypassing the blockade”, and...

在“要先获取信息”这一缺点上我觉得区别不大，比如说 domain fronting 你也要先获取相关配置，区别在于它公开后 GFW 也不容易封 *I don't think there is much difference in the drawback of “you need to obtain information first”. For example, with domain fronting, you also...

我说的重点一直在于这个配置公开后 GFW 容不容易封，**也就是对大多数人而言是不是 serverless**，因为如果要每个人都自己去搭反向代理，那还不如直接搭一个通用代理，**在这里我们要的是即使把配置给 GFW 看，GFW 也不好封的东西，也就是 domain fronting** *The main point I have been making is whether it is easy for the GFW to block this configuration after it...