Project X Channel pinned «我看到这条消息下面有一些辩论，我的看法是： 1. 中国人已经对付 GFW 十几年了，每个人都积累了大量经验，连我的专用 GitHub 账号都有五年了，而你们才刚开始两年，就觉得自己足够 clever、比我们的大量经验还 clever、不听建议，时间会证明你们的自以为是是错误的 2. 我说过，软件水平不等于反审查水平，同理，面板好用不等于它的反审查能力强，这完全是两回事，在反审查方面应当采纳反审查项目的建议，而非面板项目的建议 3. 虚拟货币的钱包地址本来就是公开的、交易人人可查的，不然就去用隐私币。有人一…»
Project X Channel pinned «新的一天，新的 PUA，我们的反审查之路，经历了： - 明文 HTTP 关键词被阻断 - VPN 协议被封禁 - SS 被主动探测而被封 IP、锱铢必较 - SS 等全随机数流量直接被封 IP - TLS 被过滤 SNI，甚至有白名单 - TLS 类代理被检测出 TLS in TLS 而被封端口 尤其是在 SS 时代，我们是逐个字节来分析它有没有暴露服务器是代理，有大量锱铢必较的研究，而现在你们直接默认明文 HTTP 访问面板、全盘托出，直接给我们干破防了。所以你们到底有没有反思过为什么知名反审查项目宁…»
GitHub
Xray-examples/MITM-Domain-Fronting at main · XTLS/Xray-examples
Some examples of uses for Xray-core. Contribute to XTLS/Xray-examples development by creating an account on GitHub.
这下 Xray 也开始无需代理、直连网站了（最适合伊朗）：https://github.com/XTLS/Xray-examples/tree/main/MITM-Domain-Fronting
https://github.com/XTLS/Xray-core/commit/9b7841178a4cb7d5b7ce558afa221254d8d3fa56
https://github.com/XTLS/Xray-core/commit/9b7841178a4cb7d5b7ce558afa221254d8d3fa56
🔥22
Telegram
xiaohuangbo im_furry_data in Project X
你这也太麻烦了，早就有图形化界面PixCealer对小白用户十分方便友好的域前置工具了
这与 core 无关，既然现在 Xray 支持了先 MITM 再发假 SNI 再校验指定域名证书，图形化界面就是 2dust 要考虑的事情了，你们快建议他去写
😁23👍3⚡2
Telegram
xiaohuangbo im_furry_data in Project X
对，GFW有时候并没有封IP，而是通过读取SNI来判断你访问了哪个网站，我曾经就在校园网内（代理会被发现喝茶）就用域前置来查维基百科，看谷歌和V2EX的（
😁22❤1
Telegram
xiaohuangbo im_furry_data in Project X
其实域前置能上的海外网站还是很多的，X，google，v2ex，维基百科等等。
其实已经完全满足伊朗人的上网需求了，毕竟在西方大站，支持域前置是一种“人权”的提现，是种政治正确，之前还因为CDN不支持域前置西方还爆发了示威游行来着（本来域前置就是为了反封锁，进行伪装使用的技术，专业对口GFW了属于是）
其实已经完全满足伊朗人的上网需求了，毕竟在西方大站，支持域前置是一种“人权”的提现，是种政治正确，之前还因为CDN不支持域前置西方还爆发了示威游行来着（本来域前置就是为了反封锁，进行伪装使用的技术，专业对口GFW了属于是）
啥时候他们能支持一下我想的 IP 前置 后置，比如把真正的 IP 藏 QUIC random 里，国外运营商拿着自己的私钥能解密出真正的 IP
之前我在 GitHub 上说的是藏 TLS session id 里，但它前面有个 TCP 握手不太好处理，所以 QUIC 更合适，可以被随意转发
之前我在 GitHub 上说的是藏 TLS session id 里，但它前面有个 TCP 握手不太好处理，所以 QUIC 更合适，可以被随意转发
😁18
Telegram
xiaohuangbo im_furry_data in Project X
他们现在都在搞先进的ECH去了，实际上就是把SNI加密了，对于国外用户而言，ECH是“网站隐私最后一片拼图”，其实和域前置异曲同工之妙，域前置是假的SNI，ECH是加密的SNI，有了ECH，浏览器默认支持，不需要啥第三方工具了，没动力搞IP前置了（
然而目标 IP 还是明文的，我这个能把真实目标 IP 都给隐藏了，看看能不能提交给 IETF，给 QUIC 加个默认开启的扩展更好（就像 ECH）
👍26🔥5
Telegram
xiaohuangbo im_furry_data in Project X
那就得等好长的时间了，毕竟直到现在ECH竟然还处于草案阶段，连个标准都还没发布（只有个前身ESNI的），唉，道阻且长了（
ECH 不是已经成了吗，但是 CF 只敢固定 cloudflare-ech.com 以便被封
😁19👍3
Project X Channel pinned «这下 Xray 也开始无需代理、直连网站了（最适合伊朗）：https://github.com/XTLS/Xray-examples/tree/main/MITM-Domain-Fronting https://github.com/XTLS/Xray-core/commit/9b7841178a4cb7d5b7ce558afa221254d8d3fa56»
GitHub
Release Xray-core v25.1.30 · XTLS/Xray-core
See https://github.com/XTLS/Xray-core/releases/tag/v25.3.6
XHTTP 服务端需及时升级至 v25.1.30，接下来的版本客户端将不会发送兼容性 path padding（已转移至 Referer header）以避免过长的日志
https://github.com/XTLS/Xray-core/releases/tag/v25.1.30
https://github.com/XTLS/Xray-core/releases/tag/v25.1.30
👍29❤4🔥4
Project X Channel pinned «XHTTP 服务端需及时升级至 v25.1.30，接下来的版本客户端将不会发送兼容性 path padding（已转移至 Referer header）以避免过长的日志 https://github.com/XTLS/Xray-core/releases/tag/v25.1.30»
Telegram
konsclufka in Project X
发现对于 VLESS 之类的将一个请求连接目标服务器和发送第一个 TCP Application Data 合并在一个包的协议没法代理在连接 TCP 后被动接受数据的协议。
当我在 Wireshark 看着我的 VNC 客户端开了个 TCP 连接然后无动于衷之后我就知道她等待，但是只有她主动去发送数据才能有回答，她只是开着在那里，她只是看着，最后她觉得目标超时了。
EDIT: 理论上在 VLESS 里包一个 Socks5 可以缓解这个问题，但是我没去试。
当我在 Wireshark 看着我的 VNC 客户端开了个 TCP 连接然后无动于衷之后我就知道她等待，但是只有她主动去发送数据才能有回答，她只是开着在那里，她只是看着，最后她觉得目标超时了。
EDIT: 理论上在 VLESS 里包一个 Socks5 可以缓解这个问题，但是我没去试。
Xray 的代码是几百毫秒没数据的话就只发请求头，Vision 还有 padding
👍14🔥2
Telegram
. in Project X
Warning] common/errors: This feature WebSocket transport (with ALPN http/1.1, etc.) is deprecated and being migrated to XHTTP H2 & H3. Please update your config(s) according to release note and documentation before removal.
2025/02/07 05:17:41 [Warning] common/errors:…
2025/02/07 05:17:41 [Warning] common/errors:…
没用 XHTTP 导致的，用了 XHTTP 会有这问题？
😁27🔥14🎉3⚡1
Telegram
MingJin in Project X
可是我用kcp能跑下载30m/s xhttp最高只能2.3m/s
End user：别跟我谈技术原理、道不道德，我不想听，我只关心快不快
😁40
Telegram
Alireza in Project X
我认为，如果分离下行链路和上行链路的概念可以与其他协议（如 tcp、ws、kcp 等）一起使用，而不仅仅是 xhttp，那就太好了。
本来想把上下行分离加给 VLESS，后来发觉 XHTTP 全场景都能用
👍13🔥2