To FireFox：这个确实是当时的想法，我都忘了有没有公开过，看来可能是在群里画过饼
BTW，这位 浮躁 的发言咋这么抽象？搁别的群你早被 ban 了，要不我们也 ban 了
最新的 commit 修复了 H2 偶尔会断流的历史遗留问题，请测试（gRPC 有类似问题吗？ ）
https://github.com/XTLS/Xray-core/issues/2355#issuecomment-1646156399
https://github.com/XTLS/Xray-core/issues/2355#issuecomment-1646156399
GitHub
reality h2模式切换网络断连，必须客户端重启服务 · Issue #2355 · XTLS/Xray-core
服务端：xray 1.8.3 客户端：安卓，v2rayNG客户端，最新版本 wifi和数据流量切换后，无法访问外网，客户端必须重启服务。 大佬们，是我配置出错还是怎样？ 看到有两个人遇到类似的问题，这个是h2不能避免的问题吗？ h2传家宝式bug ，同一wifi多ap，ap之间切换，或者wifi/移动数据之间切换也出这个问题。tcp就不会 主要是Xray与v2ray的h2传输方式无自动恢复连...
针对 X-UI 的安全建议
昨天看了个视频 ，发现这个问题比较严重：人们对 X-UI 的使用方式通常是 http://IP ，HTTP 是不加密的，传输内容一览无余，中间人可以直接看到你的对称密码（可用来离线解密）、非对称私钥（可用来中间人攻击）等。
所以对于配置，各个 X-UI 面板应默认关闭外网访问，并引导用户使用 SSH 转发端口。
此前在 别处 提过一句，昨天发现这个问题比想象中更严重，且必须从根源处解决掉。
所以对于配置，各个 X-UI 面板应默认关闭外网访问，并引导用户使用 SSH 转发端口。
此前在 别处 提过一句，昨天发现这个问题比想象中更严重，且必须从根源处解决掉。
补充：HTTP 的情况下“改端口和默认路径”对此并没有帮助，HTTPS 可以解决该问题。然而，那些想用“不需要证书”的协议的人，以及翻墙界基数最大的新手小白们并不会去配置证书，更不会其它骚操作，所以默认禁止明文的配置途径是非常有必要的。此外，HTTP 就是告诉 GFW 这里有 X-UI，套上 SSH 虽然不能解决时序特征问题，且连过 SSH 本身就是特征 ，但比明文强太多。操作系统都自带 SSH 客户端，端口转发也就一条命令，很简单了。
解释下“连过 SSH 本身就是特征”：比如说你想让 REALITY 伪装成外宾，GFW 却看到你连上同一 IP 的 SSH 传了一堆数据，这合适吗？其它协议同理。最佳实践是 SSH 也走代理，或者用 VPS 商家的 Web 终端。好消息是 GFW 尚未明显针对这一特征，坏消息是它可能是先藏着、默默监测。
2. 他的项目（已被隐藏的）README 的说法错误百出，就是一个智商检测器，我是不敢碰了，怕被拉低水平
3. 前脚刚污蔑 REALITY 开 0-RTT 不安全，后脚自己开了能被重放的 0-RTT，6
2. TLS 的 0-RTT 当然不安全，所以我根本就没有把它当成备选项，毕竟我们有一堆更好的方案
3. 他那东西搁谁看都是一个不安全版的 REALITY，在抄袭的基础上把一些不安全的东西放出来就沾沾自喜
4. 他又要说 REALITY 抄袭 ShadowTLS，首先它们的原理天差地别，完全是两种东西，他是揣着明白装糊涂。其次我 21 年初就提出了 ShadowTLS 的原理，你甚至可以去向 v2fly 求证，我还公开预告过，不是都给你看链接了？
5. 提醒一下他的“对比”故意避开了很多最关键的原理性异同，大多仅浮于形，避免暴露他换皮为主的事实，再给 REALITY 扣上个帽子，然而他拉来的“证据”ShadowTLSv3，其释出时间还晚于 REALITY，不尴尬吗？
2. 就是因为你自己的研究不到位，弄出了很多不安全的设计，还觉得它是安全的，所以你的 README 才会错误百出。其实我之前就看过了，我的评价是
GitHub
关于通过源ip特征和主动访问识别reality的可能性 · Issue #2358 · XTLS/Xray-core
今天在群里看到有人提出了一个关于识别reality的方法 我根据我的理解和知识储备想了一下： 使用reality，对外的特征应该是做为目标域名的一个节点 此时如果使用的是访问量较为高的域名 比如www.microsoft.com，那么通过源ip特征，应该可以做为识别reality的一个很有意义的参考： 如果该ip确实是微软域名的一个节点，那么访问量应该很多，而且访问的源ip应该来自全国各地，...
3. 简单来说因为 QUIC 支持连接迁移，所以偷别人的话能被 重定向精准识别，都不能用端口转发的借口来洗。所以 REALITY 支持 QUIC 后不会建议你去偷别人，而是偷自己当成 TUIC / Hysteria 来用。https://github.com/XTLS/Xray-core/discussions/1903#discussioncomment-5543921
4. 有位群友发现了华点，而且他也知道 TLS 的 0-RTT 不防重放，还拿来重点宣传。TLS 栈想开它不是轻轻松松，这有什么好得意的？哦对了，again，开它能被 重定向精准识别。
5. 既然对应上了他说的三个“最主要的点”，那我就补上：你的“不会每次都请求伪装站”的相关说法，一个主动探测就能精准识别。就是像以上这些东西，以及错误的说法充斥着你的项目，你让我怎么敢碰？
4. 有位群友发现了华点，而且他也知道 TLS 的 0-RTT 不防重放，还拿来重点宣传。TLS 栈想开它不是轻轻松松，这有什么好得意的？哦对了，again，开它能被 重定向精准识别。
5. 既然对应上了他说的三个“最主要的点”，那我就补上：你的“不会每次都请求伪装站”的相关说法，一个主动探测就能精准识别。就是像以上这些东西，以及错误的说法充斥着你的项目，你让我怎么敢碰？
GitHub
让reality支持quic？ · XTLS/Xray-core · Discussion #1903
有没有必要让reality支持quic来模拟http3？ 还是说现在已经支持了？
我想说经历得不多就先多看，我搞出的新东西还少吗？Xray 一开始的周更你没经历过吧？我一直都是想法太多以至于实现一直在后面追，
我经常会指出一些问题，都是真实存在的风险，
To https://t.me/projectXray/2661381
1. 自签证书不防主动探测，我只能说 good luck with that
2. 请给出信源，目前伊朗的情况研究到最后都是无脑封锁或限速
3. 不成立，why should we care?
1. 自签证书不防主动探测，我只能说 good luck with that
2. 请给出信源，目前伊朗的情况研究到最后都是无脑封锁或限速
3. 不成立，why should we care?
Telegram
Anshi in Project X
⠕⠎ ⡔⠕⡐⢑ ⡅⢤⠣ ⡢⠣⠑⢈⡔⠑⣈⠉⠪⣐⢁⠨⠌ ⠬⠒⠜⠰⢐⠒⠢⠤ ⣄⠃ ⣠⠔⠖ ⡈⢰ ⠥⠘⠓⡒⠉⠣⣂⡂⠃⢨⡐⠪ ⠍⣈⡒⠙⣄⡈⠋⠡⣠⠚⡨⡉⢘⡨⡆⣄⡉⢈
Project X Channel
To https://t.me/projectXray/2661381 1. 自签证书不防主动探测，我只能说 good luck with that 2. 请给出信源，目前伊朗的情况研究到最后都是无脑封锁或限速 3. 不成立，why should we care?
根据 Aryan K. 的建议附上了回复的是哪一条消息；该回复对事不对人，请 Anshi 不要有心理压力，如果我说错了欢迎来 debate ；本频道不止有 Xray 的更新信息，就像在 Project X 群你甚至可以聊 Xray ，如果只想接收更新信息，建议使用 GitHub 的 Watch 功能
让你“偷别人”的 REALITY 更以假乱真
众所周知，IP 地址的使用权经常易主，所以不妨查一下上一个指向/存在于你 VPS IP 的域名，选择它作为目标网站。
众所周知，IP 地址的使用权经常易主，所以不妨查一下上一个指向/存在于你 VPS IP 的域名，选择它作为目标网站。
Project X Channel
让你“偷别人”的 REALITY 更以假乱真 众所周知，IP 地址的使用权经常易主，所以不妨查一下上一个指向/存在于你 VPS IP 的域名，选择它作为目标网站。
补充说明：由于目标域名确实刚解析过该 IP，而你又很快用 REALITY 接上了，所以在外界看来该 IP 似乎并没有易主，有助于应对“收集所有解析 IP”类的威胁。该方法非常简单且广泛可用，若你开到了白名单域名解析过的 IP 就中大奖了。
感谢群友 b c 的测试，我们简单研究了河南新上的 SNI 黑名单，发现启用 TCP Timestamps 选项即可避免它的 RST 攻击式阻断，但若传播太广就
https://github.com/XTLS/Xray-core/issues/2426#issuecomment-1672957790
https://github.com/XTLS/Xray-core/issues/2426#issuecomment-1672957790
GitHub
河南新上的SNI/HOST黑名单墙 · Issue #2426 · XTLS/Xray-core
新开个issue，防止在别人的帖子回复时，打扰到别人.......