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...
https://t.me/projectXray/3985580
有没有一种可能，正经选项已经加完了，但最流行的 GUI 客户端比如 v2rayN&G 并没有加上这些选项，其次每加一个选项都要更新分享链接标准、等待各个 GUI 跟进更是灾难。允许通过 path 配置参数（或者像 seed 单独出一个聚合选项）是合适的解决方案，而不是你以为的屎山。
有没有一种可能，正经选项已经加完了，但最流行的 GUI 客户端比如 v2rayN&G 并没有加上这些选项，其次每加一个选项都要更新分享链接标准、等待各个 GUI 跟进更是灾难。允许通过 path 配置参数（或者像 seed 单独出一个聚合选项）是合适的解决方案，而不是你以为的屎山。
Telegram
dyhkwong in Project X
嫌 ?ed= 不够恶心人，还要来点更恶心的？一个 path 还得给你预处理一堆东西？breaking change 就算了，加点正经选项不舒服，非要加屎山？
https://t.me/projectXray/3985663
人家就做过点贡献就不该被喷就“说这些不是没有道理”，真的好搞孝啊，他喷我的时候又没见你出来论贡献😅何况 XHTTP 本来就是 Xray 的协议，有些人都能说出应该是客户端适配内核而不是内核适配客户端，没见有人说出其它内核若要加该协议应适配 Xray 而不是 Xray 顾虑其它内核，又搞孝了😅
人家就做过点贡献就不该被喷就“说这些不是没有道理”，真的好搞孝啊，他喷我的时候又没见你出来论贡献😅何况 XHTTP 本来就是 Xray 的协议，有些人都能说出应该是客户端适配内核而不是内核适配客户端，没见有人说出其它内核若要加该协议应适配 Xray 而不是 Xray 顾虑其它内核，又搞孝了😅
Telegram
千世 in Project X
人家对两个 ray 和 sing 的贡献都很大，说这些不是没有道理
https://t.me/projectXray/3986173
还是那句话，有没有一种可能，Xray 是第一个用 ws header 加 early data 的，用哪个 header name、怎么配置自然是我定的，破坏 tm 和其它项目的兼容性？其它项目都是后来才支持 ws header early data。至于 REALITY，有没有一种可能，当时其它项目都把 VLESS 列为 deprecated，我加个 Xray 版本号又说不考虑其它项目？
还是那句话，有没有一种可能，Xray 是第一个用 ws header 加 early data 的，用哪个 header name、怎么配置自然是我定的，破坏 tm 和其它项目的兼容性？其它项目都是后来才支持 ws header early data。至于 REALITY，有没有一种可能，当时其它项目都把 VLESS 列为 deprecated，我加个 Xray 版本号又说不考虑其它项目？
Telegram
dyhkwong in Project X
谁 tm 不会写了，请看上下文，他的 path ?ed= 是在塞私货进分享链接，让名叫 VMessAEAD 的分享链接实际上只有 Xray 能用，别人要是也想能用就得跟他塞一样屎山的代码进自己的项目里面，并且破坏和其他项目的兼容性，变成只能兼容 xray。你就看看那些个 xray 面板吧，还要听他指令他说什么就要改什么，还带 deadline 的是吧
https://t.me/projectXray/3987393
有时候真的很心累，我给那些面板说 不要搞明文 HTTP 以避免被记录，总有人跳出来说随机路径防主动探测，这都什么跟什么，感觉在对一群牛弹琴😅
有时候真的很心累，我给那些面板说 不要搞明文 HTTP 以避免被记录，总有人跳出来说随机路径防主动探测，这都什么跟什么，感觉在对一群牛弹琴😅
Telegram
GitHub in Project X
💬 New comment on Xray-core#3884 README.md: Only list secure web panels
by @RPRX
> Also, I should mention – using a 256-character path makes any idea of panel probing useless. There's no need to force the user through TLS.
What's you guys' problem?
…
by @RPRX
> Also, I should mention – using a 256-character path makes any idea of panel probing useless. There's no need to force the user through TLS.
What's you guys' problem?
…
Forwarded from GitHub
💬 New comment on Xray-core#3884 README.md: Only list secure web panels
by @RPRX
https://t.me/projectXtls/370
我发起这个 PR 的核心意图是给这些面板说：**不要搞明文 HTTP 以避免被记录**
我不懂为什么这个难以理解，为什么不断有人提 irrelevant 的“随机路径”
甚至有支持这些面板的 end-users 给我点 thumbs-down，不知道你们有没有注意到，APT-ZERO 是第一个，你们正在追寻他
多少有点搞笑，不是，是太搞笑了
Reply to this message to post a comment on GitHub.
by @RPRX
https://t.me/projectXtls/370
我发起这个 PR 的核心意图是给这些面板说：**不要搞明文 HTTP 以避免被记录**
我不懂为什么这个难以理解，为什么不断有人提 irrelevant 的“随机路径”
甚至有支持这些面板的 end-users 给我点 thumbs-down，不知道你们有没有注意到，APT-ZERO 是第一个，你们正在追寻他
多少有点搞笑，不是，是太搞笑了
Reply to this message to post a comment on GitHub.
Forwarded from GitHub
💬 New comment on Xray-core#3884 README.md: Only list secure web panels
by @RPRX
我推荐 SSH 端口转发的原因是，**每个桌面操作系统都内置了 SSH，只需要一条命令即可开启端口转发，并不困难**
自签 TLS 证书的特征过于明显，并且要占用 443 端口，会和 REALITY 冲突（非自签可能也是），所以我不推荐
至于 @mmmray 提到的订阅，我认为客户端应要求正常的 HTTPS，毕竟订阅可以是独立的地址，不需要和节点们在同一机器上
Reply to this message to post a comment on GitHub.
by @RPRX
我推荐 SSH 端口转发的原因是，**每个桌面操作系统都内置了 SSH，只需要一条命令即可开启端口转发，并不困难**
自签 TLS 证书的特征过于明显，并且要占用 443 端口，会和 REALITY 冲突（非自签可能也是），所以我不推荐
至于 @mmmray 提到的订阅，我认为客户端应要求正常的 HTTPS，毕竟订阅可以是独立的地址，不需要和节点们在同一机器上
Reply to this message to post a comment on GitHub.
Forwarded from GitHub
💬 New comment on Xray-core#3884 README.md: Only list secure web panels
by @RPRX
在这里建议再多，至今也没有一个面板遵循安全建议，就差把那行 SSH 端口转发命令贴上来了。**协议设计得再好，GFW 还是能通过明文 HTTP 拿到你的对称密码来解密流量、拿私钥来中间人攻击，或者直接封锁服务器，然后小白们又会叫“Xray 被封了”。**
我觉得非 core 开发者，以及数量最多的、这些面板最广泛的支持者们（小白）是因为缺乏专业知识而没有意识到问题的严重性。
或许我应该直接给他们说：**你一次 HTTP 明文，只要 GFW 想，你后续的代理流量对它来说都是明文，TLS、REALITY 形同虚设。**
现在意识到这个问题有多严重了吗？
Reply to this message to post a comment on GitHub.
by @RPRX
在这里建议再多，至今也没有一个面板遵循安全建议，就差把那行 SSH 端口转发命令贴上来了。**协议设计得再好，GFW 还是能通过明文 HTTP 拿到你的对称密码来解密流量、拿私钥来中间人攻击，或者直接封锁服务器，然后小白们又会叫“Xray 被封了”。**
我觉得非 core 开发者，以及数量最多的、这些面板最广泛的支持者们（小白）是因为缺乏专业知识而没有意识到问题的严重性。
或许我应该直接给他们说：**你一次 HTTP 明文，只要 GFW 想，你后续的代理流量对它来说都是明文，TLS、REALITY 形同虚设。**
现在意识到这个问题有多严重了吗？
Reply to this message to post a comment on GitHub.
Forwarded from GitHub
💬 New comment on Xray-core#3884 README.md: Only list secure web panels
by @RPRX
> 虽然我觉得这样管太宽不好
不是管太宽，**这就是目前 Xray 生态中最大的安全漏洞，因为用面板的人是最多的，可视化的东西对新手来说是最简单的**
想象一下，你是一个新手，翻出来一段时间后想自建，YouTube 上基本都是教你用面板，然后 http//ip，bingo
很难想象去年我第一次看到这样的视频时，看到 http://ip 时有多震惊，我都没想过还能有这种操作
保守估计 80% 以上的 Xray 服务端都是这样搭的，~~再这样下去我可要写 panel-killer 了，把你上 pornhub 的记录都列出来~~
Reply to this message to post a comment on GitHub.
by @RPRX
> 虽然我觉得这样管太宽不好
不是管太宽，**这就是目前 Xray 生态中最大的安全漏洞，因为用面板的人是最多的，可视化的东西对新手来说是最简单的**
想象一下，你是一个新手，翻出来一段时间后想自建，YouTube 上基本都是教你用面板，然后 http//ip，bingo
很难想象去年我第一次看到这样的视频时，看到 http://ip 时有多震惊，我都没想过还能有这种操作
保守估计 80% 以上的 Xray 服务端都是这样搭的，~~再这样下去我可要写 panel-killer 了，把你上 pornhub 的记录都列出来~~
Reply to this message to post a comment on GitHub.