本来今天想小改 XHTTP 然后发个新版，结果改得走火入魔了，所以有人买 NFT 吗：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2
OpenSea
REALITY - Project X
View item history and listings
没改协议，但如果你指的是其它 core 的支持，我压根就没指望他们支持，今年的计划是先加 TUN 再放出新客户端
Telegram
尚能饭 in Project X
xhttp又要改了？这下游支持又遥遥无期了
Removed from channel.
tcpNoDelay 那个选项就没用，看不懂就多学，少来教开发者怎么做事，自从上次我说总有英语 end user 会这样，人家现在翻译成中文了
tcpNoDelay 那个选项就没用，看不懂就多学，少来教开发者怎么做事，自从上次我说总有英语 end user 会这样，
Telegram
armin in Project X
够了，我们厌倦了所有这些更新，你改变了所有条目，你在寻找什么 rprx
示例：tcNoDelay 当你把它改为穿透时，遇到了什么问题？
示例：tcNoDelay 当你把它改为穿透时，遇到了什么问题？
刚刚看了下 TUN，突然悲从中来，十几年前我还是刚上初中的小屁孩时就用易语言网截写封包挂玩，十几年后又开始研究劫持进程流量，一点进步都没有，我草，之前搞 UDP 时同感，十几年前我就在搞 UDP 打洞和内网穿透，十几年后给你们写 UDP FullCone
那你这太惨了，我小学刚接触电脑就开始写挂，什么挂都写过，懂事了些就开始 C++ PHP JS 增查改删，之后 Go 开始流行我不小心入坑了 v2，现在正值青年天天去夜店玩，我说我是程序员人家都说我反差
Telegram
James Anderson in Project X
十几年前我就写增删改查，十几年后我还在写。
Forwarded from GitHub
💬 New comment on Xray-core#3272 License issue
by @RPRX
~~经典 License issue~~
我的看法是：
1. SS2022 由于刚出生就赶上了 GFW 对全随机数流量的全面封锁，未能普及，连中转机场都是老 SS AEAD，~~毕竟在某些人眼中自建主流、直连机场主流、国外主流都不算主流协议，就国内中转机场万年 SS AEAD 算主流，至于中转成了什么，也不算主流~~
2. 本能由 Xray 内建实现的 SS2022 却依附于外部依赖，在可维护性上并不妥，并且一直有一些 bug，~~现在更是不给用了~~
3. 所以有人 PR 换成 v2fly 的内建实现会合并，即使只有出站，~~毕竟说白了这协议动不动都没人用~~，这整件事就很无聊、浪费时间
4. 当初有人想更多 sing 的依赖进入 Xray，三个 mux、TUN 什么的，~~这情况就问你爽不爽~~，然而现在有 XMUX，TUN 也快了
Reply to this message to post a comment on GitHub.
by @RPRX
~~经典 License issue~~
我的看法是：
1. SS2022 由于刚出生就赶上了 GFW 对全随机数流量的全面封锁，未能普及，连中转机场都是老 SS AEAD，~~毕竟在某些人眼中自建主流、直连机场主流、国外主流都不算主流协议，就国内中转机场万年 SS AEAD 算主流，至于中转成了什么，也不算主流~~
2. 本能由 Xray 内建实现的 SS2022 却依附于外部依赖，在可维护性上并不妥，并且一直有一些 bug，~~现在更是不给用了~~
3. 所以有人 PR 换成 v2fly 的内建实现会合并，即使只有出站，~~毕竟说白了这协议动不动都没人用~~，这整件事就很无聊、浪费时间
4. 当初有人想更多 sing 的依赖进入 Xray，三个 mux、TUN 什么的，~~这情况就问你爽不爽~~，然而现在有 XMUX，TUN 也快了
Reply to this message to post a comment on GitHub.
Forwarded from GitHub
💬 New comment on Xray-core#3272 License issue
by @RPRX
确实挺浅显的：
1. 全随机数就算换成了 v6 也是全随机数，一时取巧而已，即使 IP 封不完也能实时阻断
2. Xray 又不是 Meta，我本来就不喜欢非必要地引入外部库去实现协议，更不会要求人家 GPL 改成 MPL，这也不可能实现
3. **并且我对推动 VLESS 以外的协议的支持没有什么兴趣**，有人 PR 才可能会收
4. 所以入口用 SS2022 的问题，可以等 VLESS encryption 与 Xray 新客户端普及后用 VLESS，**至于非 Xray 客户端，我不关心**
Reply to this message to post a comment on GitHub.
by @RPRX
确实挺浅显的：
1. 全随机数就算换成了 v6 也是全随机数，一时取巧而已，即使 IP 封不完也能实时阻断
2. Xray 又不是 Meta，我本来就不喜欢非必要地引入外部库去实现协议，更不会要求人家 GPL 改成 MPL，这也不可能实现
3. **并且我对推动 VLESS 以外的协议的支持没有什么兴趣**，有人 PR 才可能会收
4. 所以入口用 SS2022 的问题，可以等 VLESS encryption 与 Xray 新客户端普及后用 VLESS，**至于非 Xray 客户端，我不关心**
Reply to this message to post a comment on GitHub.
OpenSea
REALITY - Project X
View item history and listings
明明能 XHTTP H2/H3 通过 CDN，你自己喜欢守着 ALPN http/1.1 那是你的问题，甚至 stream-one 都有 worker 版本了，全面取代 WS
Telegram
ʌɾɪʌ in Project X
You really want my honest opinion?
Please stop releasing updates. Every time you do, I get stressed out, worrying that an important feature might stop working.
(Like the warning message for WebSocket, for example).🫠
Please stop releasing updates. Every time you do, I get stressed out, worrying that an important feature might stop working.
(Like the warning message for WebSocket, for example).🫠
至少在 XHTTP 全面普及前不会移除 WS，可能永远也不会移除
Xray 做了那么多工作以继续支持 Win7，你给我说不支持？
stream-up 上行由于无下行数据，cf 会掐断，这恰恰是下个版本解决的
你的言论让我想起以前改 FullCone 时短期内有些新问题，就有人喷是 FullCone 专版，都这样鼠目寸光那就真别搞了呗，什么新功能都不会有，守着 ALPN http/1.1 等死
又他妈浪费我时间跟你废话，下次这种傻逼能不能直接给 ban 了
Xray 做了那么多工作以继续支持 Win7，你给我说不支持？
stream-up 上行由于无下行数据，cf 会掐断，这恰恰是下个版本解决的
你的言论让我想起以前改 FullCone 时短期内有些新问题，就有人喷是 FullCone 专版，都这样鼠目寸光那就真别搞了呗，什么新功能都不会有，守着 ALPN http/1.1 等死
Telegram
ʌɾɪʌ in Project X
The main problem is that users don’t update their clients. For example, some are still using v2rayNG 1.6, which is 3 years old, and I can’t force them to update.
Or take someone using Windows 7—they can’t use XHTTP because the newer versions don’t support…
Or take someone using Windows 7—they can’t use XHTTP because the newer versions don’t support…
确实是这样，主要是因为我没有群的权限不能 ban 人，然后这种消息在那里混淆视听又不能不喷，但是喷完了又发现是浪费时间，发个频道消息给我气得
Telegram
W Fang in Project X
一边控制不住自己喷人的欲望，一边愤怒于浪费时间喷人😏👍
新东西刚出现会有些问题很正常、会修，且时间长了也会普及，Please stop releasing updates 这种言论哪个开发者看了都想骂你
Telegram
ʌɾɪʌ in Project X
Alright, fine. I just asked about something simple because I was worried about the future of the project, but now I feel better.
No need to get upset.
No need to get upset.
KobeArthurScofield 正在维护一个适用于 Win7 的新版 Go 分支，可直接拿 releases 来编译 Go 程序，欢迎宣传：
https://github.com/XTLS/go-win7/blob/build/README-zho-hans.md
https://github.com/XTLS/go-win7/blob/build/README-zho-hans.md
GitHub
go-win7/README-zho-hans.md at build · XTLS/go-win7
Special built Go for Windows 7. Contribute to XTLS/go-win7 development by creating an account on GitHub.
rPDmYQ 将 XHTTP path 中的 x_padding 移至
https://github.com/XTLS/Xray-core/pull/4298
Referer header，access log 干净了，需要先升级服务端：https://github.com/XTLS/Xray-core/pull/4298
GitHub
XHTTP config: alternative `paddingInHeader` by rPDmYQ · Pull Request #4298 · XTLS/Xray-core
Add an alternative place to add padding: the Referer header.
Put padding into query string bloats the reverse proxy access log, however I also don't want to fully disable logging.
From brow...
Put padding into query string bloats the reverse proxy access log, however I also don't want to fully disable logging.
From brow...
XHTTP 新增
https://github.com/XTLS/Xray-core/pull/4306
NFT 半个月没动静了，你不捐我不捐，谁给你们开发 Xray，所以你懂的：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2
scStreamUpServerSecs，解决了 stream-up 上行方向无下行实际数据被 HTTP 中间盒掐断、长连接应用断线的问题：https://github.com/XTLS/Xray-core/pull/4306
GitHub
XHTTP server: Add `scStreamUpServerSecs`, enabled by default by RPRX · Pull Request #4306 · XTLS/Xray-core
#4113 (comment) 的相关测试发现 CF 会掐断下行 100 秒无实际数据的 HTTP，导致 stream-up 的上行方向被掐断，所以这个 PR 为服务端添加了 scStreamUpServerSecs，默认值 "20-80" 取随机，服务端每隔这段时间就会发 xPaddingBytes 个字节以保活
这项机制只应针对新客户端（因为旧客户端会...
这项机制只应针对新客户端（因为旧客户端会...
肯定要优先适配规模最大的 CDN，XMUX 的默认值还是适配 Nginx 的
并且这项机制是通用的，因为其它 HTTP 中间盒可能也有类似的行为
并且这项机制是通用的，因为其它 HTTP 中间盒可能也有类似的行为
Telegram
风扇滑翔翼 in Project X
面向cf的限制编程