Project X Channel
18.3K subscribers
24 photos
1 file
609 links
Download Telegram
我们即将给 Vision 添加 Seed 支持,它可以自定义 padding 等参数,还可以设置是否开启 XTLS 模式,若不需开启,则可以配合 H2 / gRPC / WSS 等其它传输层使用,这样的能力也会加给 Switch。
👍91🔥104🎉4👀42😁1
今年 IPLC、中转也比较火,我说一下它们的本质以及风险。

先说 IPLC,首先企业能合法地买到专线,但是把它散售给普通个人绝对是违规的是要被处理的。你现在能买到专线节点,只是因为一些企业给低级监管部门的某些人交了好处费,他们睁只眼闭只眼。注意这个好处费是交不到上级决策层的,人家不缺这点。一旦有人用专线机场干了啥事,那就不光是被拔线的问题了,利益相关人士有一个算一个都得进去。

普通中转也是类似的模式,机房都知道你在干啥,睁只眼闭只眼罢了。注意这些 IPLC、中转没有任何稳定性可言,他们脆弱到任何人打个举报电话就会被清退,只能跑路。

今年机场全是这些东西是有原因的,GFW 把机场常用协议都给封了,机场是没办法,就算成本高风险大也得上中转甚至 IPLC,导致有些小白认为这就是最终解,还有更白的会说机场也用 SS 都不封。那么问题来了,既然机场全是这些东西了,你觉得 GFW 会不会打击?几年后还有没有这些东西都是问题,即使有,价格也不是普通个人能承受的。

所以不要一对比什么就 IPLC、中转,它们根本没有资格和我们努力研发的各种 anti-censorship 协议相提并论。
👍148😁1915🔥2
这个 炮 是什么啊,我说的是最基本的 anti-censorship,以及 IPLC、中转翻墙方式的脆弱性,你在这儿扯啥呢?再说就算 IPLC 线路再好,几年后买不到还有啥用?
😁25👍102🔥2
IPLC 不是“不过墙”吗?直连协议不是直接过墙吗?都是翻墙,对比不是很正常?这叫八竿子打不着??还有你确定 REALITY 需要 IPLC?你确定 Tor 不先翻墙能用?
🔥16👍32
Tor 那些网桥不就是自带翻墙吗?关于我说的 IPLC,你没理解的是它本身就是一种翻墙方式(因为它“不过墙”),而不只是单纯的线路,能不能先把这个搞明白?
🔥11👍42
这么说吧,IPLC 就是把“翻墙”这件事交给了线路,你用 IPLC 能成功翻墙,起决定性因素的是 IPLC 还是上面的协议?
👍27😁123🔥3
所以说 IPLC 本身就是一种翻墙方式啊,都是翻墙,怎么就和直连翻墙协议“八竿子打不着”了?对比它们不是很正常?
😁31🔥126👍6
Xray-core v1.8.1+ 增强版 XUDP 有多好玩?

协议:VLESS + ANY,无论有没有配置 Mux

常见误区:必须配置 xudpConcurrency?非必须,VLESS、Mux 默认就是增强版 XUDP

1. 执行 ./xray x25519,任选一串 base64
2. 设环境变量 XRAY_XUDP_BASEKEY 为它
3. 启动 Xray,用 NatTypeTester 测一下
4. 重启 Xray,再测,服务端出口端口不变
5. 连接手机热点,再测,UDP 仍保持映射

注:服务端无需配置,客户端设环境变量

其实最后一项(切换网络仍保持映射)不需设环境变量,例如,v2rayNG 1.8.5+ 默认启用

白话文:双端升级,啥都不做就有该功能

设环境变量只是为了重启 Xray 仍保持映射,例如,直连切到 CDN(落地服务端相同)
49👀10🔥9👍8😁43
关于环境变量:有没有一种可能,Xray 将会允许你在配置文件中覆写环境变量

Update:1.不是重复造轮子 2.这么设计自然有一些考量(好处)在里面,不建议瞎猜
🔥18😁6👀3👍21
To FireFox:这个确实是当时的想法,我都忘了有没有公开过,看来可能是在群里画过饼

BTW,这位 浮躁 的发言咋这么抽象?搁别的群你早被 ban 了,要不我们也 ban 了
😁24👍5🎉3
2023 上半年日常:REALITY 出了吗
2023 下半年日常:Switch 出了吗
45😁289👀6👍5🔥3
半年前 Project X Channel 的订阅数为 5K,短短半年,它翻倍到了 10K,感谢支持!
🎉20220👍15🔥7😁75👀1
针对 X-UI 的安全建议

昨天看了个视频,发现这个问题比较严重:人们对 X-UI 的使用方式通常是 http://IP ,HTTP 是不加密的,传输内容一览无余,中间人可以直接看到你的对称密码(可用来离线解密)、非对称私钥(可用来中间人攻击)等。

所以对于配置,各个 X-UI 面板应默认关闭外网访问,并引导用户使用 SSH 转发端口。

此前在 别处 提过一句,昨天发现这个问题比想象中更严重,且必须从根源处解决掉。
😁42👍335🔥52👀2🎉1
补充:HTTP 的情况下“改端口和默认路径”对此并没有帮助,HTTPS 可以解决该问题。然而,那些想用“不需要证书”的协议的人,以及翻墙界基数最大的新手小白们并不会去配置证书,更不会其它骚操作,所以默认禁止明文的配置途径是非常有必要的。此外,HTTP 就是告诉 GFW 这里有 X-UI,套上 SSH 虽然不能解决时序特征问题,且连过 SSH 本身就是特征,但比明文强太多。操作系统都自带 SSH 客户端,端口转发也就一条命令,很简单了。
😁26👍193👀2🔥1
解释下“连过 SSH 本身就是特征”:比如说你想让 REALITY 伪装成外宾,GFW 却看到你连上同一 IP 的 SSH 传了一堆数据,这合适吗?其它协议同理。最佳实践是 SSH 也走代理,或者用 VPS 商家的 Web 终端。好消息是 GFW 尚未明显针对这一特征,坏消息是它可能是先藏着、默默监测。
👀38👍23😁72🔥21
1. 不会有人把 sessionid 换成 random 就当成什么不得了的 feature 创新吧😅
2. 他的项目(已被隐藏的)README 的说法错误百出,就是一个智商检测器,我是不敢碰了,怕被拉低水平
3. 前脚刚污蔑 REALITY 开 0-RTT 不安全,后脚自己开了能被重放的 0-RTT,6
31😁10👀6👍2🔥21
1. 看到消息是因为有人在群里转发了链接,往上翻,我没空天天看其它群
2. TLS 的 0-RTT 当然不安全,所以我根本就没有把它当成备选项,毕竟我们有一堆更好的方案
3. 他那东西搁谁看都是一个不安全版的 REALITY,在抄袭的基础上把一些不安全的东西放出来就沾沾自喜
4. 他又要说 REALITY 抄袭 ShadowTLS,首先它们的原理天差地别,完全是两种东西,他是揣着明白装糊涂。其次我 21 年初就提出了 ShadowTLS 的原理,你甚至可以去向 v2fly 求证,我还公开预告过,不是都给你看链接了?
5. 提醒一下他的“对比”故意避开了很多最关键的原理性异同,大多仅浮于形,避免暴露他换皮为主的事实,再给 REALITY 扣上个帽子,然而他拉来的“证据”ShadowTLSv3,其释出时间还晚于 REALITY,不尴尬吗?
👍29👀11😁54🔥2