TGViewer
Channel Public Channel
Project X Channel

Project X Channel

@projectxtls

Donation: https://github.com/XTLS/Xray-core/issues/3668

中文群组：https://t.me/projectXray

Русский: https://t.me/projectVless

Persian: https://t.me/projectXhttp

GitHub: https://github.com/XTLS
Open in Telegram
Subscribers
29.9K
Photos
208
Videos
3
Links
1.1K
Recent Posts 20 shown
Post #3553 3.03K

Forwarded from GitHub

💬 New comment on Xray-core#6810 MASQUE transport: Add HTTP/2 (Extended CONNECT, RFC 8441)
by @RPRX

简单看了下代码，对 h2 而言 Chrome 指纹是 default（但 https://github.com/XTLS/Xray-core/pull/6807 的 h3 默认没开 ChromeParrot，~~没看能不能开~~），h2、h3 都默认不发 Chrome UA（这点与 XHTTP 以及 Xray-core 里其它 HTTP 请求相反）但支持那些特殊值，不过对于这些我暂不确定哪种默认值对 MASQUE 最合适所以等更多反馈后再调整，ALPN 决定 h2/h3 的逻辑也与 XHTTP 相反，毕竟 MASQUE 主场是 h3

说起来对于 XDRIVE 我还没细看指纹和 UA，设想是与 XHTTP 对齐吧，另外 MASQUE 似乎也能引入 XMUX https://github.com/XTLS/Xray-core/pull/6748#issuecomment-5752780799

~~至于 WARP，如果其它仓库明确兼容它且没被 DMCA 的话也不是不能支持，Aether 也可以参考，AWG 也是 https://github.com/XTLS/Xray-core/issues/6710#issuecomment-5575450166~~

Reply to this message to post a comment on GitHub.
  • 👍 11
  • ❤ 5
  • 🤩 3
Post #3552 3.05K

Forwarded from GitHub

💬 New comment on Xray-core#6828 Burst observatory: Cancel pending HTTP checks
by @RPRX

~~搞得我开始怀疑是不是有人给 AI 下达了自动给 Xray PR 的指令~~

这三个 Burst observatory 的 PR 先合为一个吧不然有点刷屏，~~XHTTP 的那俩可能也能合一起~~，然后先讨论下哪些修改能接受吧

Reply to this message to post a comment on GitHub.
  • 💘 7
  • 💅 3
  • 🆒 3
Post #3551 3.51K

Forwarded from GitHub

💬 New comment on BBS#44 墙的倒掉，已经进入按天的倒计时？
by @RPRX

内容没看不过光这标题就已经很搞笑了，我早说过只要国内那些种类繁多的内容审查的法律法规存在着，墙就不会被撤掉，不然前者原地变成空气，举个例子比如你封杀了户子，然而人家直接跑境外平台开号，然后这境外平台又能无梯直连，这跟没封杀有啥区别？点到为止不要键政

因为说白了各种内容审查乃至各种墙的实质主要是两大阵营在争权，~~在各自的地盘里放对方的黑料、洗脑自己的民众什么的，同时通过各种手段封杀对自己不利的黑料、打压对对方有利的言论~~，没有绝对的对错毕竟你上你也干，那些二极管只能证明他智商过低或有利可图，别那么傻

不过必然的尴尬就是两大阵营实控的舆论地盘肯定是一大一小，所以为了势均力敌，~~小的那方必然显得得更极权、手段更直接一些比如动不动就 404、给你上个臭名昭著的 GFW，不然小的那方早就被吞并了，而大的那方手段可以隐蔽些比如收买媒体、顺势占一些价值观制高点什么的~~

说这些既没有站谁也没有给 GFW 找补，毕竟我生理性反感那些封杀下架什么的，只是从两个底层角度来解读 GFW 的存在，换别的星球若有稳定的两大阵营也没差，不然一定早就大吞小，~~另外我越来越发现我也生理性反感某些傻逼，感觉智商没发育及格，这也并非骂人而是字面意思~~

Reply to this message to post a comment on GitHub.
  • 👍 29
  • 🤣 12
  • 🌭 8
  • ❤ 1
  • 🌚 1
  • 💋 1
  • 🎄 1
  • 🆒 1
Post #3550 3.52K

Forwarded from GitHub

💬 New comment on BBS#46 CDN代理WebSocket时开启Early Data的风险
by @RPRX

虽然文章经 AI 润色了但风险确实存在，其实开 VLESS Encryption 就行了不用停用 ed，前者是因为不信任 CDN，后者是不想让 CDN 知道你在跑代理？~~然而 CDN 若想查的话都能查出来，停不停用 ed 没差~~，或者换 HTTPUpgrade，它的 ed 机制不是写 header 里、不会进专属 log，但那些 worker & page 不方便开 enc 或换 hu，但可以 XHTTP，再说 WS/HU 有 ALPN 问题本就不被推荐，**现在过 CDN 只推荐 XHTTP + VLESS enc**

总之就是 XHTTP 天生没有 ALPN、延迟等问题，另外过 CDN 最好开个 VLESS enc，~~虽然其实很多人在用 WARP，感觉都挺信任 Cloudflare 的~~

Reply to this message to post a comment on GitHub.
  • 🏆 14
  • 😁 4
  • ❤ 3
  • 👍 2
  • ❤‍🔥 1
  • 🌭 1
Post #3549 6.18K
Project X Channel 哎surge能和singbox、mihomo平起平坐了
别笑了别笑了，既然要锐评就锐评完，事实上几天前我更新了 https://github.com/XTLS/Xray-core/issues/6477#issuecomment-5651846548 ，提到了 dyhkwong 的错误也是很重要的一点即 REALITY 旧版代码并没有“假定第一个 key share 必然是 X25519”，然后现在想想才发现“协议设计者在设计协议之初未考虑到 TLS 的潜在变化”的言论可能也是基于此，我说过根据我的设计的时间节点，REALITY 客户端直接切到含 X25519MLKEM768 的指纹并没有明显的兼容性问题，因为当时适合偷的网站都不怎么支持 X25519MLKEM768，仅此一条就已经杀死比赛，刚看了 dyhkwong 已经折叠那个 issue 的所有言论并 unpin 了，但是有一说一我还是会很感谢 dyhkwong 对 Xray-core 代码的审计，并希望他能继续这样做

不过至于 drownrat 那玩意儿我根本就不想理，说我评价别的软件的指纹不准确，无所谓啊无伤大雅又不影响我要搞的指纹筛选，再说我也根本没兴趣天天盯着隔壁的代码看啊，反而他们的那些错误恰恰是这个月加七月底两个 issue 的根基不然也不会发，这两波都直接拆家了属于是
GitHub Xray-core v26.7.11 与 mihomo v1.19.28 REALITY 不兼容，连接全部提示 authentication failed · Issue #6477 · XTLS/Xray-core 问题描述 服务端 Xray-core 从 v26.6.27 升级到 v26.7.11 后，使用 mihomo v1.19.28 作为客户端连接所有 REALITY 节点均失败。 服务端降级回 v26.6.27 后恢复正常。 配置未做任何修改，仅替换 xray-core 可执行文件。 环境信息 服务端： Xray 26.7.11 go1.26.5 Linux amd64 客户端： Mihomo...
  • 👍 27
  • 🌭 5
  • 🆒 4
  • ❤ 3
  • 😁 3
  • ☃ 2
  • 👏 1
Post #3548 5.67K

Forwarded from 蛇滴

哎surge能和singbox、mihomo平起平坐了
  • 😁 56
  • 🤣 24
  • 🗿 5
  • 👏 1
  • 🌭 1
  • 💯 1
  • 🏆 1
Post #3547 5.72K

Forwarded from GitHub

💬 New comment on Xray-core#6807 Proxy: Add MASQUE outbound & transport (IETF CONNECT-IP, RFC 9484)
by @RPRX

再多说一点其实就是，有死要面子活受罪的比如 Surge 刘某人，还有“只要 RPRX 支持的就必须是错的”比如 sing-box 世某人的 CDN 是滥用等言论，还有可能是为了兼容性而“把选择权交给用户”的 Mihomo，他们当初还说我批评面板呢，**真给我整笑了机场专用内核的白得不能再白的用户自己竟然有选择的能力说是，我说过历史会证明我推的一系列默认/强制的安全策略是正确的**

Reply to this message to post a comment on GitHub.
  • 👍 39
  • 😁 8
  • 🆒 4
  • 💅 2
  • 😍 1
  • 🌭 1
  • 💯 1
Post #3546 5.59K

Forwarded from GitHub

💬 New comment on Xray-core#6807 Proxy: Add MASQUE outbound & transport (IETF CONNECT-IP, RFC 9484)
by @RPRX

> 让AI把usque缝进去也就几分钟的事情

说得对但是其实吧我对 AI 写的代码没有任何偏见，我说白了我不懂隔壁那些内核那么喜欢搞功能性代码有什么用，AI 时代只要想的话任何功能都是一天就能搞出来，而真正有价值的其实是维护者的正确的理念，以及天马行空的想法以及把它们固化为标准的执行力 https://github.com/XTLS/Xray-core/pull/6773#issuecomment-5755516423 ，隔壁那些内核最近看我很不爽但我无所谓，**因为我知道只要我想，任何时候都能直接取而代之**

Reply to this message to post a comment on GitHub.
  • 👍 14
  • 🏆 7
  • 🔥 3
  • ❤ 2
  • 👌 2
  • 💋 1
  • 🆒 1
Post #3545 7.98K

Forwarded from GitHub

💬 New comment on Xray-core#6773 proxy/tun: configure system DNS on Linux TUN inbound
by @RPRX

~~Xray-core 可以更名 Xray-vibe 了，不是，我看隔壁 3x-ui 天天 vibe 也是挺香的，AI 越来越强了，要不拿赞助费充 GPT-6 Astra~~

AGI 时代 Xray 的核心价值大概是理念：“CDN、网盘等不算滥用”以及各种默认/强制的安全策略等，这些还是得靠维护者来决定

以及 VLESS 相关协议标准：将天马行空的想法设计为标准，并提供两端可互联的预构建 core，下载就能直接运行、节点可分享

还有 VLESS Encryption 这种最好是由人来写、相对一劳永逸的核心加密，~~至于其它的非核心代码，说实话 vibe 一个月要啥有啥~~

Reply to this message to post a comment on GitHub.
  • 👍 57
  • 😁 27
  • ❤ 3
  • ⚡ 3
  • 🆒 3
  • 🎄 2
  • ❤‍🔥 1
  • 🤣 1
  • 💋 1
  • 😎 1
Post #3544 7.55K

Forwarded from GitHub

💬 New comment on Xray-core#6748 XDRIVE transport: Add the Google Drive and "template" backend
by @RPRX

@Risaro 之前讨论过，“利用聊天/邮箱等服务”这类直接并入 XDRIVE 就行，区别是这些服务可能有主动推送而不用自己去扫 list

~~不过对于聊天软件，审查者本来就严管，比如中国就把境外的全封了，即使用境内的，比如微信语音会检查语言数据是否合理~~

XDRIVE 目前需改为默认 h2+uTLS（若 ALPN 仅 h1 那么只在内层用），以及基于魔改版 quic-go 库引入 h3 https://github.com/XTLS/Xray-core/pull/6754#issuecomment-5751585906

另外需加上配置检测：强制 VLESS Mux 以及 VLESS Encryption，后者是因为瓶颈不在终端，树莓派跑都没压力，默认更安全吧

由于有 mux 所以也就一条 enc，后者自带可配置 padding 以淡化初次握手的长度特征，以及改成“google-drive”方便分享链接

我们这边也会按计划增强一下 mux，加些选项、改改默认值，不止是 XDRIVE 必选，用处还挺多的，今年内也会加进分享链接

关于上文提到的 XMUX，大概需要把 XHTTP 里的相关代码抽出来做成独立模块，以及跨传输层联动“上下行分离”，晚点会实现

Reply to this message to post a comment on GitHub.
  • ❤‍🔥 25
  • 👍 18
  • ❤ 4
  • 💋 3
  • 🕊 1
Post #3543 9.1K
Project X 💬 New comment on Xray-core#6748 XDRIVE transport: Add the Google Drive backend by @RPRX 为了凑到第 2000 个 commit ~~以及给 Risaro 的生日补个礼物~~，我打算现在就分两步合并 XDRIVE 相关的 PR 进 main 代码仍需完善，比如上面我提到的 XMUX，以及 config 的“Google Drive”改为“google-drive”，以及检测配置：需开启 mux.cool ~~可能还需要一些…
Xray-core 已合并 XDRIVE 进 main，第 2000 个 commit，对于俄罗斯、伊朗用户，需先配置好 Google Drive API，记得开 mux.cool，并将 SNI 设为 www.google.com，若某地访问不了 Google，可以试试 template

XDRIVE 不仅无视 IP 白名单，还能白名单 SNI domain fronting，至于速度，Google Drive 看起来还不错，其它服务看你们能不能找到快的

评论区有说国内的，额不要自作多情，这协议延迟略高且吞吐量略低，对于国内而言大概永远也成不了主力，除非你追求非常别致的隐蔽翻墙
GitHub XDRIVE transport: Add the Google Drive and "template" backend by Risaro · Pull Request #6748 · XTLS/Xray-core This stacks on #6745. Until that one is merged the diff here also contains its commit. What it adds A Storage implementation for Google Drive, selected with "service": "G...
  • 👍 97
  • 😁 18
  • 👏 14
  • 🤣 4
  • 🆒 3
  • 🏆 2
  • 😈 2
  • ❤ 1
  • 👀 1
  • 💘 1
  • 😎 1
Post #3542 12.1K

Forwarded from GitHub

💬 New comment on Xray-core#6477 Xray-core v26.7.11 与 mihomo v1.19.28 REALITY 不兼容，连接全部提示 authentication failed
by @RPRX

> ~流窜AI那边准备一年内接管互联网了，人类开发者还在争论指纹~

能不能别搞笑了这争论的是指纹吗？分明就是某些人看我不爽又干不掉我所以只能天天拿些鸡毛蒜皮的小事/张冠李戴来攻击我以及 Xray 的事

反正所有问题就必须是我的问题、大问题，不如让我们回顾一下今年我和哪些傻逼对线过：

1. Sukka 看到 REALITY 仓库 maxUselessRecord 是 16 就直接高潮，甚至给我写了七千字小作文，然而我早就给它改成 32 了，16 是别人误改
2. 刘某人韭菜割多了自信心爆棚，竟敢说我不了解 ShadowTLS 的实现细节，结果发现尴尬的是自己，被我喷到退休、连 Surge 论坛都关了
3. 小唐人预告拉满，都以为它要整一波大的结果却拉了坨大的，PoC 全面误伤正常网站，后面根据我写的 TODO 的 PoC 甚至也检测不出来
4. drownrat 自己搞错了死不承认，只能硬磕当时没几个人用的 pcs 算 CVE9，甚至眼瞎没看到 v26.2.6 明确写了让用户升级，只能把我拉黑怕我继续揭穿他，当然最搞笑的还是这傻逼要手搓“核弹”，它那“核弹”其实是它认为的我的小号在推特上的历史发言，自己洗脑自己了属于是
5. dyhkwong 的误导性言论刚刚我已经分析过了，弄出这畸形的指纹只能说是卧龙凤雏，毕竟 Xray 从一开始就没搞过这种指纹也没什么问题，并且若用户迟迟不更新 Xray 服务端那么甚至 Xray 自己的客户端都连不上，畸形指纹兼容的是哪家服务端不言而喻，要么就是故意的

相信大家都看明白了，这些傻逼的落脚点就是要踩我，至于什么理由不重要，甚至根本不是我干的事也能把帽子扣我头上，甚至没什么影响范围的事也必须是十分严重的问题，我早习惯了，早在去年某些人借 uTLS 指纹问题想顺带踩死 REALITY 时我就说过，“任何问题都必须是 Xray 的非常严重的问题”，今年这些事能让大家看得更清楚，**当然更傻逼的是这些狗喜欢通过小圈子/私密群来拉人头，就连什么都不懂的小白用户都要被他们拉出来给他们点赞，然而这些事情并不是你拉赞多你就占理，最终历史会给出公正的评判，届时只会更加揭露他们是跳梁小丑的本质**

Reply to this message to post a comment on GitHub.
  • 👍 94
  • 😁 23
  • 💯 12
  • ❤ 10
  • ⚡ 6
  • 🕊 3
  • 🌭 2
  • 💋 2
  • 👏 1
  • 💅 1
Post #3541 10.2K

Forwarded from GitHub

💬 New comment on Xray-core#6477 Xray-core v26.7.11 与 mihomo v1.19.28 REALITY 不兼容，连接全部提示 authentication failed
by @RPRX

https://github.com/ExclaveNetwork/Exclave/issues/480#issuecomment-5647030654 依旧稳定发挥了 dyhkwong 基于屁股说话只说一半、断章取义误导观众的传统艺能：

首先又是上次掰扯过的问题，虽然当时风扇确实没给我说，更没有他们脑补的“我授意”什么的，**但 Xray-core v26.2.6 确实也写了“v26.2.6 包含一些 v26.1.23 新增功能的配置项变更、重要修复，请及时升级 Xray-core 以及 GUI 客户端”，我没改，web archive 自己去看，能别狗叫了不？** 其次又是跟 drownrat 学的车轱辘句式，他们口口声声的“漏洞”指的是当时没几个人用的 pcs 参数，**妄图以极小搏极大来糊弄过去“那些个客户端让本能用上 X25519MLKEM768 的用户降级到 X25519”的问题，毕竟后者影响面可是基于 REALITY 庞大用户基数的大多数非 Xray 客户端，抛开影响面谈安全问题/漏洞是诡辩，试图掩盖真正的核心问题是无耻**，无视我推动的那么多安全策略却拿没几个人用的参数来论证“不配”更是可笑，甚至我根本就没干那事，~~学到了 Sukka 和 drownrat 的精髓说是~~，提醒升级的 release notes 倒是我写的，后面 pcs 也是我强推才流行的

> 中间人拿到客户端配置对用户 MITM 属于用户不按照操作方式使用导致的自食其果，不属于协议问题。即使如此，基于 TLS 的协议仅拿到客户端配置仍然无法 MITM。REALITY 等魔改 TLS 认证流程的协议属于自己制造了别的协议不存在的问题再自己解决。

类似于“抛开影响面、抛开 release notes”的说话只说一半，~~这抛开不谈咋这么眼熟~~，**光说“制造了别的协议不存在的问题”却丝毫不提“解决了别的协议没解决的问题”，你那单纯套个 TLS 的协议是能妥善解决 SNI 白名单的问题还是说你要自签证书加 allowInsecure？甚至没我强推 pcs 的话这问题都没被摆到主流台面上来**，以前的 Trojan、现在的 AnyTLS 机场多流行这套组合你们也门清，至于自建，大概率又是“属于用户不按照操作方式使用导致的自食其果”，那问题是机场用户基本上是小白、自建用户基本上是大白，跟着教程甚至一键脚本冲就完了根本就不懂那些，**况且即使是 pin 证书也不如 REALITY 这类方案，它们虽然不完美但至少在持续进步，至于“中间人拿到客户端配置对用户 MITM”让用户自食其果，是你能保证用户的客户端配置不漏还是？以前说过很多可能性就不重复了，所以解决了这问题的协议它就是比没这解决问题的协议更先进**

最后终于到 trim 掉 X25519MLKEM768 的问题了，dyhkwong 口口声声辩护这一行为，~~“协议本身恶心”其实是“协议必须恶心”~~，**却没有告诉你 Go 程序使用 uTLS 的初衷就是“符合浏览器 Client Hello”，那你都 trim 掉了 X25519MLKEM768 你还是个 der 的浏览器 CH 啊这不搞笑吗？我说过就算回落到旧版 Chrome 指纹也比这强啊，他同样没有告诉你的是 Xray-core v25.5.16 即 REALITY 服务端支持 X25519MLKEM768 那一版开始，Xray 客户端的 Chrome 指纹就是默认指向带 X25519MLKEM768 的最新版，我们也没遇到什么大问题啊，官方尚且如此，第三方实现对齐官方行为不就行了，有什么必要留畸形的指纹？甚至一年后官方明确说了不能搞这种，一年多了还不能改？是为兼容还是实际上懂的都懂，他更没有告诉你的是客户端带上 X25519MLKEM768 而连不上旧版服务端在当时只是极少数，这就是为什么像 Xray 直接切新指纹本就完全可行**

Reply to this message to post a comment on GitHub.
  • 👍 43
  • ❤ 8
  • 👏 7
  • 🤩 3
  • ❤‍🔥 2
  • 🌭 2
  • 💯 2
  • ☃ 1
  • 🔥 1
  • 🏆 1
Post #3540 9.47K

Forwarded from GitHub

💬 New comment on Xray-core#6477 Xray-core v26.7.11 与 mihomo v1.19.28 REALITY 不兼容，连接全部提示 authentication failed
by @RPRX

关于 https://github.com/ExclaveNetwork/Exclave/issues/480#issuecomment-5615081269 ：

REALITY 的本质是服务端 MITM，同时也是真正的 TLSv1.3，**精妙地继承了 TLSv1.3 的前向安全等一揽子安全设计同时还强制 pin**，这是 REALITY 与类似目标的其它协议的最大的不同之处，当然既然已经是 MITM 了那么服务端肯定要升级才能支持新的加密套件比如 X25519MLKEM768，并非 dyhkwong 所述的“协议设计者在设计协议之初未考虑到 TLS 的潜在变化”，**毕竟你不可能在一开始就支持未来才会出的加密套件**，dyhkwong 在其叙事中屡次基于刻意偏见把 REALITY 描述成“已经进行并且将来也会不得不持续进行破坏性变更”却丝毫不提 REALITY 的本质及安全特性，且虽然 REALITY 的认证依赖 CH 中的 X25519 但就算不依赖，**仅“看起来正常的 MITM”这一条就需要你更新服务端以支持新的加密套件**，至于依赖 CH 中的 X25519 进行认证也是 REALITY 的安全设计即 **GFW 仅拿到客户端配置无法对你 MITM**，而绝大多数别的“土制协议”是从未考虑过这一点的，这些也是 dyhkwong 不会告诉你的，甚至 REALITY 抗量子更新第二弹 加的 ML-DSA-65 更是将这一安全设计提前覆盖到了后量子时代

再说说指纹的问题，所有人都知道 nekohasekai 自那场搞笑“论战”过后就没有跟进过包括其 fork 的 REALITY 仓库在内的几乎任何更新，若不是他们后来统一用 Mihomo 的 uTLS fork 附带 REALITY ~~那估计这辈子你都看不到 sing-box 服务端支持 REALITY X25519MLKEM768~~，[Xray-core v25.5.16](https://github.com/XTLS/Xray-core/releases/tag/v25.5.16) 写的是“所以服务端一定要及时升级，避免新版客户端连不上”、“等一两个月后其它网站陆续开始支持了，大家的服务端早就升级、兼容了”但我也不说这个点了，Xray v25.5.16 版本开始的 Chrome 指纹就是带 X25519MLKEM768 的，也就是说 Xray 生态的服务端若不及时升级就连不上，那大家猜猜那些客户端 trim 掉 X25519MLKEM768 主要是为了兼容哪家的旧版客户端呢？甚至我觉得这还不是最大的重点，**最大的重点是都过去一年了还搞这种奇怪的指纹是要 [恶心谁](https://t.me/projectXtls/3539?comment=5242816)？不复当年 uTLS 出个指纹问题就想顺带把 REALITY 说死那次了？所以我总是说吧有些人它就是屁股歪，若非要说是“为了兼容”那么若没有这种指纹纵容，反而所有服务端早就升级了，甚至在协议作者明确说不能搞这种奇怪的指纹后某些人愣是不改，亘古未有啊，那我只能在服务端把这种指纹过滤掉以确保至少 Xray 搭出来的 REALITY 不会受此影响，~~都是这个世界的错~~**

Reply to this message to post a comment on GitHub.
  • 👍 55
  • ❤ 15
  • 👏 7
  • 🎉 5
  • 🤔 4
  • ☃ 2
  • 💯 2
  • 🔥 1
  • 😎 1
Post #3539 10.7K

Forwarded from GitHub

💬 New comment on Xray-core#6477 Xray-core v26.7.11 与 mihomo v1.19.28 REALITY 不兼容，连接全部提示 authentication failed
by @RPRX

> > @iciness xray升级到26.9.9后reality又无法连接了人都麻了
>
> mihomo代理配置里reality-opts:下加入support-x25519mlkem768: true 另外，服务端miniClientVer可以先删掉了

由于主要针对 Client Hello 缺少 X25519MLKEM768 的问题，Xray 最新版本做出了更精确的调整，Mihomo 加上述参数即可 https://github.com/XTLS/Xray-core/issues/6714#issuecomment-5581324161

看到“关爱世界委员会”的 Exclave 作者发的这篇声明 https://github.com/ExclaveNetwork/Exclave/issues/480 就特别想笑，从头到尾捋一下这种奇怪的指纹怎么来的：

1. 2023 年 nekohasekai 给 Xray-core 开了一些包含 SagerNet/* 组件的 PR，我们觉得维护不便&路线冲突故予以拒绝，简单来说这些代码应当直接 PR 到 Xray-core 仓库而不是引用别的仓库、增加维护/修改成本，~~后面更是发现是 GPL~~，难以维护且被收回授权的 SS2022 就是例子
2. 有了这样的导火索，nekohasekai 从此天天找茬 Xray，直至同年九月爆发了“TLS in TLS 是炒作”的论战，他认为该项检测不现实/成本高，甚至在没看 Trojan-killer 代码的情况下脑补它的实现原理并进行批评，闹出了很大的笑话，还趁热打铁在其博客连发两篇春秋笔法、错误百出的小作文，~~讽刺的是，后来“关爱世界委员会”成员推出了“旨在解决 TLS in TLS”的 AnyTLS，nekohasekai 不提炒作了甚至早点了 star~~
3. 2025 年中 REALITY 支持了 X25519MLKEM768，虽然这需要升级服务端和客户端，但由于当时并没有多少网站支持它所以留足了升级的时间，**然而 sing-box 因上述纠葛迟迟不更新 REALITY 服务端的代码，导致后来只有 trim 掉 X25519MLKEM768 才能连上 sing-box 服务端**，虽然 Xray 从未这样做过且也没什么大问题，但包括 sing-box 在内的一些其它客户端为了兼容 sing-box 服务端而搞出了这种奇怪的指纹

这根本不是 REALITY 搞了多大的破坏性更新，而是 sing-box 故意迟迟不更新 REALITY 服务端代码的人祸，再往上究其原因就是 1、2 点所述的历史纠葛，Exclave 作者 dyhkwong 对上述三点只字不提，且 X25519MLKEM768 本来就会使连接更加安全而不单是 parrot 与否的问题，uTLS 主线 Firefox、Safari 指纹支持它至少半年了而不是“recent”，没有发版只是因为维护人手不足，dyhkwong 与其基于屁股、冠冕堂皇且无耻地把所有问题都归责于 Xray、呼吁“boycott Xray”，不如反思下你们这“关爱世界委员会”有没有关注过用户的数据安全问题，~~还说什么翻墙是伪命题~~

Reply to this message to post a comment on GitHub.
  • 👏 70
  • 💯 16
  • ❤ 15
  • ❤‍🔥 7
  • 🍾 5
  • 👍 3
  • 😁 2
  • 🥰 1
Post #3538 11.6K
Project X 26.9.8这个更新猛啊，ClientHello强制X25519MLKEM768，Stash、Quantumult X、Shadowrocket、Loon这几个客户端都干趴下了😏
Xray-core 更个版本，变成异常指纹检测器了，不改不知道一改吓一跳
GitHub Release Xray-core v26.9.9 · XTLS/Xray-core Sponsors Sponsor Xray-core Donation & NFTs Collect a Project X NFT to support the development of Project X! TRX(Tron)/USDT/USDC: TNrDh5VSfwd4RPrwsohr6poyNTfFefNYan TON: UQApeV-u2gm43aC1uP7...
  • 👍 45
  • 🤣 20
  • 🔥 6
  • 🍾 3
  • ❤ 2
  • 🤯 2
Post #3537 12.2K
这就是为什么我现在遇到阴阳人就直接 ban 了，一个个的都有什么大病

https://github.com/XTLS/Xray-core/commit/47cfe9994a6b39b1f673ba35e62b091bcce15a71#commitcomment-199503450
GitHub Update github.com/xtls/reality to 20260908062103 · XTLS/Xray-core@47cfe99 https://github.com/XTLS/REALITY/commit/8cdf7bf9c7f09cb9814bf08c3eb877f68b85fba8 https://github.com/XTLS/REALITY/commit/e1986a4d31ca33c087a72ab4644aef1295693b69 https://github.com/XTLS/REALITY/commi...
  • 👍 59
  • 🤩 10
  • 🌚 6
  • 🍓 3
  • 🗿 3
  • 💅 2
  • ❤ 1
  • 💋 1
Post #3536 18.3K

Forwarded from 震火🐾🐾😈/Ember

奇怪的快感
  • 🌭 117
  • 😁 28
  • 🤣 12
  • ❤‍🔥 4
  • 😈 2
  • ❤ 1
  • 🏆 1
  • 🍓 1
  • 💅 1
  • 😎 1
Post #3535 17.5K

Forwarded from 震火🐾🐾😈/Ember

华为翻墙有一种
  • 🌭 89
  • 🤣 28
  • 😈 6
  • 🗿 2
  • ❤ 1
  • ☃ 1
  • 🤩 1
  • 👌 1
  • 💯 1
Post #3530 23.8K

Forwarded from Pai

  • 🤣 68
  • ❤ 9
  • 😍 6
  • 👏 3
  • 🆒 1
Older posts →

About this channel

How can I read @projectxtls without a Telegram account?
TGViewer shows the public web preview Telegram publishes for Project X Channel: recent posts, photos, videos and the subscriber count, with no app, login or account.
How many subscribers does Project X Channel have?
Project X Channel (@projectxtls) has 29.9K subscribers on Telegram, refreshed roughly every 30 minutes.
Does Project X Channel know I viewed it here?
No. Public channel previews carry no viewer identity, and TGViewer has no accounts or tracking of what you look up.
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →