Forwarded from GitHub
💬 New comment on Xray-core#3823 xmux for grpc and h2
by @RPRX
I'm waiting for XHTTP, and I will not release the next version of Xray-core until XHTTP is ready, ~~or there will be no next version.~~
Reply to this message to post a comment on GitHub.
by @RPRX
I'm waiting for XHTTP, and I will not release the next version of Xray-core until XHTTP is ready, ~~or there will be no next version.~~
Reply to this message to post a comment on GitHub.
提醒：价格为 0.1ETH 的 Project X NFT 仅剩一个，此后价格为 0.15ETH 起步
这就叫共识
https://github.com/XTLS/Xray-core/discussions/3633
https://github.com/XTLS/Xray-core/discussions/3633
GitHub
Announcement of NFTs by Project X · XTLS/Xray-core · Discussion #3633
Background 自初始创立的近四年来，Project X 几乎是这里仅有的不收任何赞助、不收任何广告，也没有任何“产业”的项目组。 因为我们创立 Project X 的初衷是捍卫人们自由获取与表达信息的基本人权，anti-censorship，do something good，而不是为了任何经济利益，即使我们已经投入了大量的时间精力、所创造的价值更是难以估量，我们也没有从中拿过一分钱...
Forwarded from GitHub
💬 New comment on Xray-core#3819 Transport: Add HTTP3 to HTTP
by @RPRX
请大家测试一下新的直连 H3 传输层的可用性，~~并且我们有计划给它加上不那么 brutal 的增强~~
Reply to this message to post a comment on GitHub.
by @RPRX
请大家测试一下新的直连 H3 传输层的可用性，~~并且我们有计划给它加上不那么 brutal 的增强~~
Reply to this message to post a comment on GitHub.
Forwarded from GitHub
💬 New comment on Xray-core#3851 求大哥拉我入tg群啊，回答错误了4次问题
by @RPRX
这种bt的问题已经存在几年了，其实最开始我觉得风扇设置的这些问题~~严重限制了群人数的增长~~，但后来我觉得人不在多而在精，入群考验的是独立查找答案的能力~~以及一点点运气~~，只有这样才能保证群的高质量交流，~~以及珍惜留在群里的资格不要违反群规~~
Reply to this message to post a comment on GitHub.
by @RPRX
这种bt的问题已经存在几年了，其实最开始我觉得风扇设置的这些问题~~严重限制了群人数的增长~~，但后来我觉得人不在多而在精，入群考验的是独立查找答案的能力~~以及一点点运气~~，只有这样才能保证群的高质量交流，~~以及珍惜留在群里的资格不要违反群规~~
Reply to this message to post a comment on GitHub.
Forwarded from GitHub
🔌 New pull request Xray-core#3852 Transport: Add RAW as an alias of TCP
by: @RPRX
几年前就想这么干了，这下顺眼多了，新版发布后文档应作出对应修改，只写
Reply to this message to post a comment on GitHub.
by: @RPRX
几年前就想这么干了，这下顺眼多了，新版发布后文档应作出对应修改，只写
raw 和 rawSettingsReply to this message to post a comment on GitHub.
Forwarded from GitHub
💬 New comment on Xray-core#3819 Transport: Add HTTP3 to HTTP
by @RPRX
> > 请大家测试一下新的直连 H3 传输层的可用性，~并且我们有计划给它加上不那么 brutal 的增强~
>
> 感谢 测试了一下可以正常使用~ 不过测速表现可能比以前的 quic 稍差一点 因为复用同一链接的关系 如果连续测速跟 quic split 一样会有明显降速的情况 （可能跟我测试线路有关）
多了一点点数据头，~~理论上会比直接的 QUIC 慢 1%~~，实际上几乎没差，它和 SplitHTTP 合并为 XHTTP 后就有 xmux 能限制复用了
外层都是 quic-go 的特征，感觉暂时不适合 fallbacks 或 REALITY，实际部署应放在 Nginx 后面，改它的 QUIC 拥塞控制就能提速
所以我觉得现阶段多加一点点数据头换来能放在反代软件后面是很值得的，这也是 XHTTP 和 Hysteria / TUIC / Juicity 的最大区别
Reply to this message to post a comment on GitHub.
by @RPRX
> > 请大家测试一下新的直连 H3 传输层的可用性，~并且我们有计划给它加上不那么 brutal 的增强~
>
> 感谢 测试了一下可以正常使用~ 不过测速表现可能比以前的 quic 稍差一点 因为复用同一链接的关系 如果连续测速跟 quic split 一样会有明显降速的情况 （可能跟我测试线路有关）
多了一点点数据头，~~理论上会比直接的 QUIC 慢 1%~~，实际上几乎没差，它和 SplitHTTP 合并为 XHTTP 后就有 xmux 能限制复用了
外层都是 quic-go 的特征，感觉暂时不适合 fallbacks 或 REALITY，实际部署应放在 Nginx 后面，改它的 QUIC 拥塞控制就能提速
所以我觉得现阶段多加一点点数据头换来能放在反代软件后面是很值得的，这也是 XHTTP 和 Hysteria / TUIC / Juicity 的最大区别
Reply to this message to post a comment on GitHub.
Forwarded from GitHub
💬 New comment on Xray-core#3819 Transport: Add HTTP3 to HTTP
by @RPRX
> NGINX 的 stream 模块不支持quic，测试版是支持的，正式版就删除了。好像没法通过sni分流 https://github.com/nginx/nginx/issues/146
~~Nginx 支持 QUIC 只是时间问题~~，鉴于可预见的未来内暂无服务端 QUIC 特征伪装方案，Xray 放在反代软件后面是非常有必要的
我重来，才看清说的是 stream，我还纳闷 Nginx 咋会还不支持 H3，然而 Xray 用到的不是 stream 而是 H3 反代（变为 H2/H1）
根据 H2 传输层的 [文档](https://xtls.github.io/config/transports/h2.html)，它可以被 Nginx 中转，但似乎未经测试（这也是我最初希望上下行分离的原因之一），可以测试一下 Nginx 支持这种全双工吗？不过我现在决定即使 Nginx 不支持，XHTTP 也会支持这种经典的全双工模式
Reply to this message to post a comment on GitHub.
by @RPRX
> NGINX 的 stream 模块不支持quic，测试版是支持的，正式版就删除了。好像没法通过sni分流 https://github.com/nginx/nginx/issues/146
~~Nginx 支持 QUIC 只是时间问题~~，鉴于可预见的未来内暂无服务端 QUIC 特征伪装方案，Xray 放在反代软件后面是非常有必要的
我重来，才看清说的是 stream，我还纳闷 Nginx 咋会还不支持 H3，然而 Xray 用到的不是 stream 而是 H3 反代（变为 H2/H1）
根据 H2 传输层的 [文档](https://xtls.github.io/config/transports/h2.html)，它可以被 Nginx 中转，但似乎未经测试（这也是我最初希望上下行分离的原因之一），可以测试一下 Nginx 支持这种全双工吗？不过我现在决定即使 Nginx 不支持，XHTTP 也会支持这种经典的全双工模式
Reply to this message to post a comment on GitHub.
Xray-core v24.9.30: https://github.com/XTLS/Xray-core/releases/tag/v24.9.30
GitHub
Release Xray-core v24.9.30 · XTLS/Xray-core
XMUX (multiplex controller) for SplitHTTP
这是 Xray-core 改变版本号规则后的首个 stable 版本，正如 v1.8.24 所预告的，该版本的重要更新主要有：
SplitHTTP 传输层的 XMUX：https://xtls.github.io/config/transports/splithttp.html
HTTP 传输层的 H3：h...
这是 Xray-core 改变版本号规则后的首个 stable 版本，正如 v1.8.24 所预告的，该版本的重要更新主要有：
SplitHTTP 传输层的 XMUX：https://xtls.github.io/config/transports/splithttp.html
HTTP 传输层的 H3：h...
Forwarded from GitHub
💬 New comment on Xray-core#3819 Transport: Add HTTP3 to HTTP
by @RPRX
> nginx貌似只能反代grpc的h2流量，没有h2c的反代功能。其实只要xray传输层的http支持http1.1就行了？nginx接收h3流量用http/1.1反代给后端xray。
这两天我和 @yuhan6665 也在研究这件事，Nginx 暂不支持 h2c 回源，所以 H2 传输层的文档写 Nginx 是错的，应该写 Caddy。以前缺乏 Web 伪装大概也是 H2 传输层几乎没人用的原因之一（另一个原因是 v2 有断流 bug），就像此前被删掉的 QUIC 传输层。
HTTP/1.1 的流式上行也需要 chunked encoding，还没测 Nginx 是否支持把 h3/h2 转译成它，然后还有些问题需要研究。
Caddy 或许还支持把 h3 转译成 h2c，正在测试，但那样又成 quic-go 了，~~感觉 Caddy 像玩具~~，能用主流的 Nginx 更好。
> 另外测了下裸奔的vless+h3+tls，性能符合预期能跑满，但不如hy2，除了qos限流外，好像还会断流要重启客户端才行。还有就是没有伪装功能
目前只推荐放在反代软件后面，我们计划修改 Nginx 的 QUIC 拥塞控制代码，就像其它协议改 quic-go，但不会那么 brutal。
至于断不断流，盲猜代码应该没那种断流 bug，可能是运营商给你 Q 没了，需要换本地端口，以后也支持 xmux 就能自动换了。
总体上还是 SplitHTTP 比较成熟，基本上什么都支持什么都有了，即使上行 Split 也问题不大，毕竟通常上行流量很少。打算把 v24.9.30 标为 latest，下个版本可能 xmux 会有默认值以及 path 也能设置参数，XHTTP 是合并还是单独指代直连还在考虑。
Reply to this message to post a comment on GitHub.
by @RPRX
> nginx貌似只能反代grpc的h2流量，没有h2c的反代功能。其实只要xray传输层的http支持http1.1就行了？nginx接收h3流量用http/1.1反代给后端xray。
这两天我和 @yuhan6665 也在研究这件事，Nginx 暂不支持 h2c 回源，所以 H2 传输层的文档写 Nginx 是错的，应该写 Caddy。以前缺乏 Web 伪装大概也是 H2 传输层几乎没人用的原因之一（另一个原因是 v2 有断流 bug），就像此前被删掉的 QUIC 传输层。
HTTP/1.1 的流式上行也需要 chunked encoding，还没测 Nginx 是否支持把 h3/h2 转译成它，然后还有些问题需要研究。
Caddy 或许还支持把 h3 转译成 h2c，正在测试，但那样又成 quic-go 了，~~感觉 Caddy 像玩具~~，能用主流的 Nginx 更好。
> 另外测了下裸奔的vless+h3+tls，性能符合预期能跑满，但不如hy2，除了qos限流外，好像还会断流要重启客户端才行。还有就是没有伪装功能
目前只推荐放在反代软件后面，我们计划修改 Nginx 的 QUIC 拥塞控制代码，就像其它协议改 quic-go，但不会那么 brutal。
至于断不断流，盲猜代码应该没那种断流 bug，可能是运营商给你 Q 没了，需要换本地端口，以后也支持 xmux 就能自动换了。
总体上还是 SplitHTTP 比较成熟，基本上什么都支持什么都有了，即使上行 Split 也问题不大，毕竟通常上行流量很少。打算把 v24.9.30 标为 latest，下个版本可能 xmux 会有默认值以及 path 也能设置参数，XHTTP 是合并还是单独指代直连还在考虑。
Reply to this message to post a comment on GitHub.
https://t.me/projectXray/3980247
请各个面板改为默认不暴露在公网并引导用户使用 ssh 转发，我将于下周一在 README 中 unlink 仍默认暴露在公网的面板，请将此消息转发给各面板的开发者
请各个面板改为默认不暴露在公网并引导用户使用 ssh 转发，我将于下周一在 README 中 unlink 仍默认暴露在公网的面板，请将此消息转发给各面板的开发者
Telegram
Nikita Korotaev in Project X
曾经，R先生写过关于面板问题的文章
https://t.me/projectXtls/165
你认为从那时起有什么本质上的变化吗？
没有！
例如，所有的3x-ui面板
LINK
例如，所有的Marzban节点
LINK
例如，所有在特定主机上使用Marzban面板基础配置的Reality服务器
LINK
这难道不是一个次要特征，可以让人识别出该IP地址被用作代理服务器吗？
这完全可以直接进行过滤。
这只是一些简单的例子，如果稍微努力一下，我还能找到成千上万个IP地址，它们被用作机场。
https://t.me/projectXtls/165
你认为从那时起有什么本质上的变化吗？
没有！
例如，所有的3x-ui面板
LINK
例如，所有的Marzban节点
LINK
例如，所有在特定主机上使用Marzban面板基础配置的Reality服务器
LINK
这难道不是一个次要特征，可以让人识别出该IP地址被用作代理服务器吗？
这完全可以直接进行过滤。
这只是一些简单的例子，如果稍微努力一下，我还能找到成千上万个IP地址，它们被用作机场。
https://t.me/projectXray/3980304
What if, the censors do not just have scanners, but also have traffic-collectors. So, the panels for Xray-core MUST do not let themselves exposed under plain HTTP.
What if, the censors do not just have scanners, but also have traffic-collectors. So, the panels for Xray-core MUST do not let themselves exposed under plain HTTP.
Telegram
Ho3ein Sanaei in Project X
I’ve taken several steps to address this issue. For example, I added an option to set a web base path during the panel installation. However, some users skip this step and leave it blank. When the web base path is correctly configured, the panel becomes undetectable…
https://t.me/projectXray/3980319
Objectively, I don't think most users of REALITY have their own certificate, and it's UNACCEPTABLE to expose private key under plain HTTP. Please, just guide users to use SSH port forwarding.
Objectively, I don't think most users of REALITY have their own certificate, and it's UNACCEPTABLE to expose private key under plain HTTP. Please, just guide users to use SSH port forwarding.
Telegram
Ho3ein Sanaei in Project X
We also display red warnings throughout the panel for users who don't have a certificate. Ignoring them increases the risk of exposure, especially with traffic collectors involved. I hope users take these warnings seriously.
https://t.me/projectXray/3980478
感谢报告，这已经不是识别的问题了，而是中间人攻击（解密）的问题了
https://t.me/projectXray/3980479
赞同，生成一下又不难，不要偷懒
感谢报告，这已经不是识别的问题了，而是中间人攻击（解密）的问题了
https://t.me/projectXray/3980479
赞同，生成一下又不难，
Telegram
Nikita Korotaev in Project X
Additionally, I would like to mention the issue of default values for sensitive settings.
EXAMPLE
For example, in the case of the panel, there has been an example configuration all this time with a preset privateKey for REALITY.
Given that most users…
EXAMPLE
For example, in the case of the panel, there has been an example configuration all this time with a preset privateKey for REALITY.
Given that most users…
https://t.me/projectXray/3982208
其实 v1.8.0 发布前我就想把 dest 改名为 target，对 REALITY 来说含义更准确一些，不过当时已经有很多 REALITY 教程了就没改，你可以开个 PR 在 json 那里加个 alias
其实 v1.8.0 发布前我就想把 dest 改名为 target，对 REALITY 来说含义更准确一些，不过当时已经有很多 REALITY 教程了就没改，你可以开个 PR 在 json 那里加个 alias
Telegram
Nikita Korotaev in Project X
For Mr. R:
Maybe we could create an alias for dest = target, just like we previously did for tcp = raw?
Maybe we could create an alias for dest = target, just like we previously did for tcp = raw?
关于翻墙生态系统的用户问卷调查：https://github.com/net4people/bbs/issues/402
GitHub
关于翻墙生态系统的用户问卷调查 / User Survey on Censorship Circumvention Ecosystem · Issue #402 · net4people/bbs
我们是来自斯坦福大学、科罗拉多大学和GFW Report的反审查研究人员，致力于了解人们如何绕过中国的互联网审查。如果您使用VPN、代理或任何其他翻墙软件绕过防火长城（GFW），请考虑花5分钟的时间帮助我们完成一份简短的调查问卷，以助我们更好地理解和改进翻墙生态系统。我们的调查问卷和整个研究已通过斯坦福大学伦理审查委员会（IRB）的严格审核。本次调查是匿名的，不会收集任何可识别参与者个人身份...
下个版本我们会为 XMUX 预设非无限的默认值，把 SplitHTTP 和 HTTP 合并为 XHTTP 传输层（相当于 SplitHTTP 支持了 REALITY，HTTP 也有了默认的 header padding 和 XMUX），XHTTP 允许通过 path 配置参数以方便 GUI 客户端与分享。
https://github.com/XTLS/Xray-core/releases/tag/v24.9.30
https://github.com/XTLS/Xray-core/releases/tag/v24.9.30
GitHub
Release Xray-core v24.9.30 · XTLS/Xray-core
XMUX (multiplex controller) for SplitHTTP
这是 Xray-core 改变版本号规则后的首个 stable 版本，正如 v1.8.24 所预告的，该版本的重要更新主要有：
SplitHTTP 传输层的 XMUX：https://xtls.github.io/config/transports/splithttp.html
HTTP 传输层的 H3：h...
这是 Xray-core 改变版本号规则后的首个 stable 版本，正如 v1.8.24 所预告的，该版本的重要更新主要有：
SplitHTTP 传输层的 XMUX：https://xtls.github.io/config/transports/splithttp.html
HTTP 传输层的 H3：h...