这下 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
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.
这与 core 无关，既然现在 Xray 支持了先 MITM 再发假 SNI 再校验指定域名证书，图形化界面就是 2dust 要考虑的事情了，你们快建议他去写
Telegram
xiaohuangbo im_furry_data in Project X
你这也太麻烦了，早就有图形化界面PixCealer对小白用户十分方便友好的域前置工具了
Telegram
xiaohuangbo im_furry_data in Project X
对，GFW有时候并没有封IP，而是通过读取SNI来判断你访问了哪个网站，我曾经就在校园网内（代理会被发现喝茶）就用域前置来查维基百科，看谷歌和V2EX的（
啥时候他们能支持一下我想的 IP 前置 后置，比如把真正的 IP 藏 QUIC random 里，国外运营商拿着自己的私钥能解密出真正的 IP
之前我在 GitHub 上说的是藏 TLS session id 里，但它前面有个 TCP 握手不太好处理，所以 QUIC 更合适，可以被随意转发
之前我在 GitHub 上说的是藏 TLS session id 里，但它前面有个 TCP 握手不太好处理，所以 QUIC 更合适，可以被随意转发
Telegram
xiaohuangbo im_furry_data in Project X
其实域前置能上的海外网站还是很多的，X，google，v2ex，维基百科等等。
其实已经完全满足伊朗人的上网需求了，毕竟在西方大站，支持域前置是一种“人权”的提现，是种政治正确，之前还因为CDN不支持域前置西方还爆发了示威游行来着（本来域前置就是为了反封锁，进行伪装使用的技术，专业对口GFW了属于是）
其实已经完全满足伊朗人的上网需求了，毕竟在西方大站，支持域前置是一种“人权”的提现，是种政治正确，之前还因为CDN不支持域前置西方还爆发了示威游行来着（本来域前置就是为了反封锁，进行伪装使用的技术，专业对口GFW了属于是）
然而目标 IP 还是明文的，我这个能把真实目标 IP 都给隐藏了，看看能不能提交给 IETF，给 QUIC 加个默认开启的扩展更好（就像 ECH）
Telegram
xiaohuangbo im_furry_data in Project X
他们现在都在搞先进的ECH去了，实际上就是把SNI加密了，对于国外用户而言，ECH是“网站隐私最后一片拼图”，其实和域前置异曲同工之妙，域前置是假的SNI，ECH是加密的SNI，有了ECH，浏览器默认支持，不需要啥第三方工具了，没动力搞IP前置了（
Project X Channel pinned «这下 Xray 也开始无需代理、直连网站了（最适合伊朗）：https://github.com/XTLS/Xray-examples/tree/main/MITM-Domain-Fronting https://github.com/XTLS/Xray-core/commit/9b7841178a4cb7d5b7ce558afa221254d8d3fa56»
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
GitHub
Release Xray-core v25.1.30 · XTLS/Xray-core
See https://github.com/XTLS/Xray-core/releases/tag/v25.3.6
给了过渡时间，一键升级服务端很难吗，v25.1.30 同时兼容新旧客户端
Telegram
taiyi747 in Project X
😅怎么感觉又像是破坏性更新
Project X Channel pinned «XHTTP 服务端需及时升级至 v25.1.30，接下来的版本客户端将不会发送兼容性 path padding（已转移至 Referer header）以避免过长的日志 https://github.com/XTLS/Xray-core/releases/tag/v25.1.30»
Xray 的代码是几百毫秒没数据的话就只发请求头，Vision 还有 padding
Telegram
konsclufka in Project X
发现对于 VLESS 之类的将一个请求连接目标服务器和发送第一个 TCP Application Data 合并在一个包的协议没法代理在连接 TCP 后被动接受数据的协议。
当我在 Wireshark 看着我的 VNC 客户端开了个 TCP 连接然后无动于衷之后我就知道她等待，但是只有她主动去发送数据才能有回答，她只是开着在那里，她只是看着，最后她觉得目标超时了。
EDIT: 理论上在 VLESS 里包一个 Socks5 可以缓解这个问题，但是我没去试。
当我在 Wireshark 看着我的 VNC 客户端开了个 TCP 连接然后无动于衷之后我就知道她等待，但是只有她主动去发送数据才能有回答，她只是开着在那里，她只是看着，最后她觉得目标超时了。
EDIT: 理论上在 VLESS 里包一个 Socks5 可以缓解这个问题，但是我没去试。
End user：别跟我谈技术原理、道不道德，我不想听，我只关心快不快
Telegram
MingJin in Project X
可是我用kcp能跑下载30m/s xhttp最高只能2.3m/s
本来想把上下行分离加给 VLESS，后来发觉 XHTTP 全场景都能用
Telegram
Alireza in Project X
我认为，如果分离下行链路和上行链路的概念可以与其他协议（如 tcp、ws、kcp 等）一起使用，而不仅仅是 xhttp，那就太好了。
这个没有自带多路复用，且 ALPN 为 http/1.1，不太能进来
Telegram
U̶nknowNㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ in Project X
You can also merge HTTPUpgrade(fake websocket) to XHTTP
要不你发 GitHub 上，新版 stream-up 的上行相当于 stream-one 了
Telegram
O_o $_$ in Project X
关于为什么设置自动压缩对象，这个是前段时间使用出现的问题，改这个比改r佬说的sse方便一点，反正体验影响不大...，你想查询当时的对话，跳转上去自己翻一下 @geek_sh
就是说假 WebSocket 标头只能 HTTP/1.1 用，且不自带任何连接复用
Telegram
Alireza in Project X
我认为我们的朋友的意思是向 xhttp 添加特定于 ws 或 hu 的标头。
在我看来 KCP 只是利用 UDP 来暴力发包，这种事 XHTTP 也不是做不到
Telegram
Alireza in Project X
确实，xhttp 使得流量看起来更自然，但是将整个上行和下行分离的概念添加到 vless 中是一个非常好的主意，因为它允许您使用除了 xhttp 之外的其他传输方式，例如 kcp 等。