Latest posts
Project X Channel
21 Sept, 04:44
💬 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.Project X Channel
20 Sept, 21:28
💬 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.Project X Channel
19 Sept, 09:18edited
💬 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 ~~可能还需要一些GitHubXDRIVE transport: Add the Google Drive backend by Risaro · Pull Request #6748 · XTLS/Xray-coreThis 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...Project X Channel
14 Sept, 03:35
💬 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 指纹问题想顺带踩死 REALITYProject X Channel
13 Sept, 07:06
💬 New comment on Xray-core#6477 Xray-core v26.7.11 与 mihomo v1.19.28 REALITY 不兼容，连接全部提示 authentication failed by @RPRXhttps://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”的说话只说一半，~~这抛开不谈咋这么眼熟~~，光说“制造了别Project X Channel
11 Sept, 08:26
💬 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 服务端支持Project X Channel
10 Sept, 02:37
💬 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，nekohasekaiProject X Channel
9 Sept, 02:22edited
26.9.8这个更新猛啊，ClientHello强制X25519MLKEM768，Stash、Quantumult X、Shadowrocket、Loon这几个客户端都干趴下了😏GitHubRelease Xray-core v26.9.9 · XTLS/Xray-coreSponsors 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...Project X Channel
8 Sept, 09:19edited
这就是为什么我现在遇到阴阳人就直接 ban 了，一个个的都有什么大病https://github.com/XTLS/Xray-core/commit/47cfe9994a6b39b1f673ba35e62b091bcce15a71#commitcomment-199503450GitHubUpdate github.com/xtls/reality to 20260908062103 · XTLS/Xray-core@47cfe99https://github.com/XTLS/REALITY/commit/8cdf7bf9c7f09cb9814bf08c3eb877f68b85fba8 https://github.com/XTLS/REALITY/commit/e1986a4d31ca33c087a72ab4644aef1295693b69 https://github.com/XTLS/REALITY/commi...Project X Channel
2 Sept, 10:10
奇怪的快感Project X Channel
2 Sept, 10:10
华为翻墙有一种Project X Channel
28 Aug, 02:53
Project X Channel
27 Aug, 19:48
软件开源协议：mit mpl gpl 线路开源协议：realityProject X Channel
19 Aug, 14:54edited
弱弱的说一下，最先开创这种平台架构的是v2ray，在clash之前，必须为v姐正名Project X Channel
19 Aug, 06:18edited
各位的锐评已经很多了，让我评价一下就是，可能从 end 但非 endest user 看来就是这样，只知道 SS 和破分流啥的，Surge 能被提到确实更是忠实信徒，我觉得吧分流等客户端侧各种功能倒不能说是没创新，有些功能的确是别人第一个写出来的也不能否认，只是这不是只要在写相关的代码就一定会写出来的东西吗？换任何人来早点开发不都一样？顶多是比谁出生更早、闻道有先后罢了，如果还有人看不懂的话，以物理来做个不是很贴合的比喻就像是上个世纪底层原理的爆发和这个世纪基础理论几近停滞但应用一大堆一样，这么多年了 Xray 给众人的实际感受就是前者而不是后者，后者等 288 刀吧Project X Channel
18 Aug, 07:58
我的ip被标记了吗请问
Project X Channel
18 Aug, 06:33
Project X Channel
10 Aug, 08:24
这次不小心写多了，就不完整复制到频道了 https://github.com/2dust/v2rayN/discussions/9870#discussioncomment-17950357GitHub[风险通知]: Xray 26.1.13-26.6.27版本 自签证书+pinsha256的TLS 存在MITM风险漏洞 · 2dust v2rayN · Discussion #9870如果您使用v26.1.13 到v26.6.27版本的Xray核心，并且使用自签证书+pinsha256的TLS安全层（Reality不受影响，正规CA证书的TLS安全层不受影响，更早更晚的Xray不受影响），请立刻更新至26.7.11+版本来避免Xray官方拒绝披露的恶性MITM风险漏洞Project X Channel
9 Aug, 07:46edited
又乱喷，一会儿 AI 一会儿小号的，还“明眼人提醒”，唉好吧其实 GitHub 上全是我的小号，反正有 AI 加持我也不累，这下闭环了 Mihomo 的代码是默认 trim，虽然有不 trim 的选项这点比 sing-box 强点，但也一言难尽，这下开始比烂了 本来我确实已经没理你了，你又发篇小作文我才把你 block，在这里又不得不回应你是因为你对 Xray 进行了恶意指控“Xray官方拒绝披露的恶性MITM风险漏洞”，没完没了的就，我当时就猜测你对上个月修的那个问题理解错了，事实也确实如此，它在实GitHub[风险通知]: Xray 26.1.13-26.6.27版本 自签证书+pinsha256的TLS 存在MITM风险漏洞 · 2dust v2rayN · Discussion #9870如果您使用v26.1.13 到v26.6.27版本的Xray核心，并且使用自签证书+pinsha256的TLS安全层（Reality不受影响，正规CA证书的TLS安全层不受影响，更早更晚的Xray不受影响），请立刻更新至26.7.11+版本来避免Xray官方拒绝披露的恶性MITM风险漏洞Project X Channel
7 Aug, 15:42edited
又是发生在singbox官方群的一幕，一伊朗用户要求支持xhttp遭受集体围攻（骂的过于难听+我准备截图时候消息被世界大手删了没来得及截图），现已被世界踢出有关所有群聊+永久block
Related Channels
Other channels in the same section of the catalogue.
