关于证书内容为3500字节及以上，且支持X25519MLKEM768的网站

[MoRanYue]

是否有更多网站，可使Reality支持ML-DSA-65签名验证呢？

这里目前仅仅知道，github.io与*.github.io符合需求呢。

$ xray tls ping github.io
TLS ping:  github.io
Using IP:  185.199.110.153:443
-------------------
Pinging without SNI
Handshake succeeded
TLS Version:  TLS 1.3
TLS Post-Quantum key exchange:  true (X25519MLKEM768)
Certificate chain's total length:  4645 (certs count: 3)
Cert's signature algorithm:  SHA256-RSA
Cert's publicKey algorithm:  RSA
Cert's allowed domains:  [*.github.io *.github.com *.githubusercontent.com github.com github.io githubusercontent.com www.github.com]
-------------------
Pinging with SNI
Handshake succeeded
TLS Version:  TLS 1.3
TLS Post-Quantum key exchange:  true (X25519MLKEM768)
Certificate chain's total length:  4645 (certs count: 3)
Cert's signature algorithm:  SHA256-RSA
Cert's publicKey algorithm:  RSA
Cert's allowed domains:  [*.github.io *.github.com *.githubusercontent.com github.com github.io githubusercontent.com www.github.com]
-------------------
TLS ping finished

scmp.com应当亦可以使用呀（不过，它被托管于Cloudflare呢）。

$ xray tls ping scmp.com
TLS ping:  scmp.com
Using IP:  104.18.204.43:443
-------------------
Pinging without SNI
Handshake succeeded
TLS Version:  TLS 1.3
TLS Post-Quantum key exchange:  true (X25519MLKEM768)
Certificate chain's total length:  4750 (certs count: 3)
Cert's signature algorithm:  SHA256-RSA
Cert's publicKey algorithm:  RSA
Cert's allowed domains:  [*.scmp.com scmp.com]
-------------------
Pinging with SNI
Handshake succeeded
TLS Version:  TLS 1.3
TLS Post-Quantum key exchange:  true (X25519MLKEM768)
Certificate chain's total length:  4750 (certs count: 3)
Cert's signature algorithm:  SHA256-RSA
Cert's publicKey algorithm:  RSA
Cert's allowed domains:  [*.scmp.com scmp.com]
-------------------
TLS ping finished

[ZqinKing]

acme貌似申请不出符合的证书，不到3000长度

[limetw]

可以，我用的是google
加上 --keylength 4096 试试

[la88962]

可以，我用的是google 加上 --keylength 4096 试试

大神,我也是用acme的,兩個域名同時申請rsa 4096证書也只能達到2850!完全没法達到3500+,请問如何用google 申請证書方法？

[lxhao61]

用 ACME 从 ZeroSSL 申请 RSA 证书可以。

[la88962]

用 ACME 从 ZeroSSL 申请 RSA 证书可以。

成功了,感謝大神🙏🙏🙏

[lxhao61]

成功了,感謝大神🙏🙏🙏

客气了，欢迎入坑。🤝

[limetw]

TLS Version: TLS 1.3
TLS Post-Quantum key exchange: true (X25519MLKEM768)
Certificate chain's total length: 4268 (certs count: 3)
Cert's signature algorithm: SHA256-RSA
Cert's publicKey algorithm: RSA

我的域名似乎符合要求，但是用不了。
用别人的，几天后被QoS 300kb

[limetw]

已找到原因，我之前nginx启用了ssl_client_certificate

[limetw]

www.umcg.nl
这个域名用了几天，被QoS了
YouTube 默认144p 切换其他画质卡的无法观看
测速也就300kb，换成自己的域名就满速

[MoRanYue]

www.umcg.nl 这个域名用了几天，被QoS了 YouTube 默认144p 切换其他画质卡的无法观看 测速也就300kb，换成自己的域名就满速

（这里目前一直使用github.io，似乎并没有被QoS的迹象呀（福建省 中国电信））

[jjlizz]

www.umcg.nl 这个域名用了几天，被QoS了 YouTube 默认144p 切换其他画质卡的无法观看 测速也就300kb，换成自己的域名就满速

这是什么原理，运营商捣鬼？

[MoRanYue]

（这里发现，www.ucl.ac.uk与www.cuhk.edu.hk亦满足需求呢）

[Cirooo]

题外话，是不是如果选用Reality，就不能用nginx反代这种模式了？我目前的是

traffic => nginx => server_name => [xray, site1, site2, site3 ...]

[Cirooo]

啊？明显吗，都是https流量，443端口。只是它们域名不一样而已。

[MoRanYue]

（emm，考虑到 Reality为修改后的TLS v1.3，或许并不支持Nginx前置代理呀）
（这里目前，仅对TLS使用Nginx代理，若使用Reality入站，则使用直连呀：

       XHTTP (gRPC/SSE) + TLS          XHTTP (gRPC/SSE) + TLS       Unix域套接字
Client <--------------------> CDN Edge <--------------------> Nginx <---------> Xray Inbound (VLESS+XHTTP+TLS)

Client <----------------------------------------------------------------------> Xray Inbound (VLESS+XHTTP+Reality)

）

[Cirooo]

虽然还有一种方案，就是xray替代Nginx作为前段代理。再说吧，我只是好奇问一下这两者是不是这么回事，现在也有答案了。谢谢各位😆

[MoRanYue]

虽然还有一种方案，就是xray替代Nginx作为前段代理。再说吧，我只是好奇问一下这两者是不是这么回事，现在也有答案了。谢谢各位😆

（这里使用Nginx作为前置代理，不过只是希望Xray与正常的网站，能够共用443端口呀。这里认为，若没有类似的需求，应该并不需要使用前置代理呢）

[Cirooo]

对，我因为在这个小服务器上有个git，还有自己写的一套试验应用，从那个时期开始就共用443了，最近还加了nextcloud跟vaultwarden，还挺好，1G内存+swap至今还活着✌

[kuraudowelle]

我前几天也在纠结这个问题，换来换去的。但是后面不纠结了，还是偷邻居或者自己最好
X25519MLKEM768是迟早的事，IP的相似度更高其实更重要我觉得

[MoRanYue]

（a，毕竟，目前似乎没有大规模应用的量子计算机呀）

[n0nsense11]

已经测出来的有c.media-amazon.com（以及与之同证书的，托管于cloudfront），www.tp-link.com（托管于cloudfront），tgstat.ru（托管于cloudflare）,files.biglybt.com（托管于cloudfront），aws.amazon.com，duckduckgo.org（以及与其同证书的域名。被sni rst的竟然只有duckduckgo.com，但访问其他域名会自动跳转到主站，所以长时间挂着其他域名的sni跑流量也是一种异常。spreadprivacy.com是一个不会跳转的域名），www.paypal.com（以及同证书的域名，托管于fastly），www.nationalgeographic.com（托管于cloudfront），www.ieee.org（以及同证书，托管于cloudfront），www.un.org（托管于cloudfront）,www.boeing.com（以及同证书，托管于cloudfront）,www.qualcomm.com（托管于cloudflare），www.yahoo.com（以及同证书，不过鉴于yahoo已经不向中国大陆提供服务，挂着yahoo的sni跑流量也是一种异常），*.dmm.com（托管于cloudfront，dmm本身的地域限制可能会让流量被认为存在异常？），www.broadcom.com（以及同证书，托管于cloudflare），www.asus.com（托管于cloudfront），wifiman.com（托管于cloudfront）
sni显示为github.io会不会被gfw丢包处理？不太清楚gfw对github干扰的手段和范围

[MoRanYue]

sni显示为github.io会不会被gfw丢包处理？不太清楚gfw对github干扰的手段和范围

（福建地区基本完全封锁github.io，根本无法访问：但其可能为地区性防火墙所致，这里并不知晓其它地区的情况呀）

[MoRanYue]

（另外，gitlab.com将被跳转至about.gitlab.com，nsone.net将被跳转至my.nsone.net，它们均不满足要求呀；tp-link.com将被跳转至www.tp-link.com，它满足要求。）

[n0nsense11]

（另外，gitlab.com将被跳转至about.gitlab.com，nsone.net将被跳转至my.nsone.net，它们均不满足要求呀；tp-link.com将被跳转至www.tp-link.com，它满足要求。）

确实，已修改

[jjlizz]

感谢外网一个老哥的工作

https://www.netmeister.org/blog/pqc-use-2025-03.html

他扒出来了截止2025.03时候大量支持抗量子的域名，大概有30000个，我自己写了个简单的脚本，通过他的列表用xray检查域名是否真的支持X25519MLKEM768，长度是否大于3500，筛选结果在我的附件列表当中，有1100+个域名，分享给大家，但是注意，这些域名我只检测了是否支持抗量子和是否长度达标，域名本身是否已经被墙，或者网站内容是否包含敏感危险内容我没有精力进一步验证，请使用前自行分辨。

PQlist.txt

[MoRanYue]

（谢谢。这里尝试使用脚本，得到了所有 不被用于重定向，且暂时未被封锁的734个域名呀）

cleaned_pqc_domains.txt

[jjlizz]

@MoRanYue 细化了下，把符合条件，不被重定向（或被重定向后的域名仍然符合条件），curl返回200且国内能ping通的，列了个表出来，这些应该是严格确定可用的，还有个疑似可用的列表，这里面主要是符合条件但是curl被拒绝访问的，这些域名因为网站的访问策略没有办法依靠脚本简单测试是否被重定向，放在存疑列表当中有兴趣的可以自行手动验证。
pqc_domains.txt
doubt_domains.txt

[404gods]

我一直都是Vless reality vision，偷自己的网站，昨天也搞定了自己的网站证书，用ACME从ZeroSSL申请，满足X25519MLKEM768，长度大于3500，xray连接日志也成功显示： is using X25519MLKEM768 for TLS' communication: true

[lxhao61]

表述不严谨，从 ZeroSSL 申请的 RSA 证书仅满足长度大于 3500。
是否满足 X25519MLKEM768 是由 Caddy 版本(实为 Go 库的版本)或由 Nginx 的 SSL 库版本或其它 WEB 网站所决定的。

[404gods]

是的，我忘记说了nginx要重新编译openssl版本要满足要求。

[jjlizz]

在网上找了个top 10million domain的列表，去掉重复域名，只保留根域名和www二级域名，大概还剩650万个，写了个脚本拿服务器慢慢跑，判断符合条件，在墙内能够正常访问（200响应），没有重定向或者重定向的网站还是符合条件的网站，哪怕是并行检测还是得花个一星期，等跑完大概就能做到域名自由了（

[SKIPPINGpetticoatconvent]

直接脚本测试好了，选着用吧
working_domains.txt

[SKIPPINGpetticoatconvent]

只排除了地理位置为中国的所有域名

[jjlizz]

从top10m list里面选出来的，只包含无跳转的根域名和www二级域名，过滤中国域名，过滤被墙域名，检测通过的域名放到了pqc list里面，一共是四万多个域名，还有一些xray tls ping的证书检测通过，但是网站因为访问策略无法通过脚本检测可访问性的放到了doubt list里面，因为网页跳转和域名归属判定不可能100%准确，所以用之前还是推荐手动检测一下，这下实现域名自由了
pqc_domains.txt
doubt_domains.txt

[MoRanYue]

从top10m list里面选出来的，只包含无跳转的根域名和www二级域名，过滤中国域名，过滤被墙域名，检测通过的域名放到了pqc list里面，一共是四万多个域名，还有一些xray tls ping的证书检测通过，但是网站因为访问策略无法通过脚本检测可访问性的放到了doubt list里面，因为网页跳转和域名归属判定不可能100%准确，所以用之前还是推荐手动检测一下，这下实现域名自由了 pqc_domains.txt doubt_domains.txt

哈哈哈哈哈哈，老哥，你这个第一个就是个 H 网啊 🤣。
里面有比较多用 cloudflare 的站点，也不太适合，我又过滤了下：没使用 cloudflare && 支持 x25519mlkem768 的站点，所剩无几。
x25519mlkem768_domains.txt

（emm，其中有许多网站，选择使用其它CDN。仅过滤Cloudflare后的结果，应该不会如此之少呀）

[jjlizz]

从top10m list里面选出来的，只包含无跳转的根域名和www二级域名，过滤中国域名，过滤被墙域名，检测通过的域名放到了pqc list里面，一共是四万多个域名，还有一些xray tls ping的证书检测通过，但是网站因为访问策略无法通过脚本检测可访问性的放到了doubt list里面，因为网页跳转和域名归属判定不可能100%准确，所以用之前还是推荐手动检测一下，这下实现域名自由了 pqc_domains.txt doubt_domains.txt

哈哈哈哈哈哈，老哥，你这个第一个就是个 H 网啊 🤣。 里面有比较多用 cloudflare 的站点，也不太适合，我又过滤了下：没使用 cloudflare && 支持 x25519mlkem768 的站点，所剩无几。 x25519mlkem768_domains.txt

这不奇怪，根据前人做的一些工作，top 1m的域名当中，只有不到2%是非CDN自己运营的，CDN当中cloudflare占了接近一半，而且只有cloudflare对于这方面的东西比较积极，你如果把它剥离掉，这其中域名既支持抗量子还要长度超过3500的基本大海捞针了，或许你可以尝试下doubt list，里面的域名符合条件，但是因为访问策略，脚本爬虫是被直接拒绝访问的，所以无法确定可访问性，但是不代表它们就不能用
我说说我的脚本的思路
1.只保留根域名和www二级域名，其他域名全部排除，同时过滤掉中国域名
2.用xray的命令检查域名是否抗量子，长度是否达标
3.在大陆服务器用curl检查域名是否可以正常访问，是否无跳转，返回200即判定可用放进list，返回重定向则返回步骤2检测跳转之后的域名，最多重复3次，返回被拒绝访问的状态码则放进doubt list

[jjlizz]

从top10m list里面选出来的，只包含无跳转的根域名和www二级域名，过滤中国域名，过滤被墙域名，检测通过的域名放到了pqc list里面，一共是四万多个域名，还有一些xray tls ping的证书检测通过，但是网站因为访问策略无法通过脚本检测可访问性的放到了doubt list里面，因为网页跳转和域名归属判定不可能100%准确，所以用之前还是推荐手动检测一下，这下实现域名自由了 pqc_domains.txt doubt_domains.txt

哈哈哈哈哈哈，老哥，你这个第一个就是个 H 网啊 🤣。
里面有比较多用 cloudflare 的站点，也不太适合，我又过滤了下：没使用 cloudflare && 支持 x25519mlkem768 的站点，所剩无几。
x25519mlkem768_domains.txt

（emm，其中有许多网站，选择使用其它CDN。仅过滤Cloudflare后的结果，应该不会如此之少呀）

就是这么少，这方面cloudflare就是绝对大头，因为这种筛选都是从top域名筛选，所以肯定CDN是主流，而CDN当中只有cloudflare对抗量子还算比较积极，你可以参考下这位的工作，你如果把cloudflare排除那连CDN当中支持抗量子的都寥寥无几
https://www.netmeister.org/blog/pqc-use-2025-09.html

[MoRanYue]

@jjlizz （好吧，毕竟许多反向代理应用（例如Nginx），其后量子加密 并非处于默认开启的状态呀）

[jjlizz]

@jjlizz （好吧，毕竟许多反向代理应用（例如Nginx），其后量子加密 并非处于默认开启的状态呀）

cloudflare的域名你就在xray加限速策略凑合用吧，这种域名多了去了gfw也不可能地毯式一个一个查