XTLS
Solution to the xpadding leak
Hello, I'd like to thank all of you for your efforts in improving xray.
In the recent update, you removed the option to disable xpadding, which is a positive step towards reducing the chance of detection. However, it seems you haven't considered that xpadding can cause traffic to be identified on certain CDNs!
I believe one solution to this problem would be to use a random 3 or 4 character string instead of x_padding, and also random characters instead of X or 0.
The prerequisite for this is that the client should accept any response header, and the server should accept any query (meaning it should be sensitive to the path but not sensitive to the query parameters).
Thank you again for your efforts. Please think more about my suggestion before dismissing it, as this is important for those of us using specific CDNs.
https://t.me/projectXtls/670
I had seen that message, and while it's true for large CDNs like Cloudflare but smaller and country-specific CDNs often try to enforce restrictions using one or a few rules. The presence of x_padding is something that helps them do this with a single rule.
For example, I noticed that on one CDN, adding a standard user-agent like Google Chrome resolved the connection issue.
Therefore, please prevent blocking by randomizing the xpadding.
@Fangliding @RPRX
Therefore, please prevent blocking by randomizing the xpadding.
我们的意思很明确，等这样的 blocking 出现后再采取措施规避它
Therefore, please prevent blocking by randomizing the xpadding.
我们的意思很明确，等这样的 blocking 出现后再采取措施规避它
As I said, this doesn't happen with well-known and public CDNs like Cloudflare, but it does happen with local CDNs. However, if your intention is for me to wait until they block and then report it, that's fine, and I'll wait. But I wish you paid as much attention to the inner layers as you do to the outer layers, such as adding default headers and so on, because many Xray users use various CDNs.
Thanks for all your work to make X-ray better.
@RPRX
However, if your intention is for me to wait until they block and then report it, that's fine, and I'll wait.
Exactly.
Therefore, please prevent blocking by randomizing the xpadding.
我们的意思很明确，等这样的 blocking 出现后再采取措施规避它
Since yesterday russian CDN named cdnvideo already throws 403 if request contains x_padding param. This blocking has already been implemented and is in effect, and many people in Russia have now lost internet access.
既然已经有了明确的只针对 x_padding 的封锁，下个版本顺便加个自定义吧，此外既然这个 CDN 已经关注 XHTTP 了，建议换一家
重申对抗 CDN 检测的思路：不要一次把手里的牌打完。比如说如果 XHTTP 早就加了 x_padding 自定义，CDN 就会检测其它方面。
我试了一下要加较为完美的自定义的话得加至少六个选项（双端长度，双端名称，双端候选字符），还没算上是否放 Referrer 什么的
我觉得，或许，还是允许禁用 x_padding 吧，不过这样会导致 req/resp header 长度较为固定，除非保证和 body 粘包，我再想想吧
it was 1 month already
https://github.com/XTLS/Xray-core/pull/5414 was closed without any normal reason
what the hell? is this abandoned now or smh
