You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bump uTLS: chrome fingerprint is still Chrome 133 #7131
Xray-core main pins utls aa6edf4, so fingerprint: "chrome" (also the default and ECH) sends Chrome 133.
uTLS 6ebdceb (2026-10-06) adds HelloChrome_155 (verified against branded Chrome) and makes it HelloChrome_Auto.
Google Chrome 155 (Linux): t13d1517h2_8daaf6152771_cb7bf5808d99
After the bump, only randomized values differ (GREASE, keys, ECH payload, extension order).
In Russia the current chrome fingerprint appears to be detected and blocked by TSPU.
Proposal: bump utls to >= 6ebdceb and add "hellochrome_155" to the fingerprint map.
@Fangliding Understood. Note that Xray is already on an untagged commit (aa6edf4, 6 commits after v1.8.2), so I thought a pinned commit was acceptable. Chrome 155 is the current stable channel, so most real Chrome traffic already looks like 155 and 133 is the outlier now.
3. @Fangliding Understood. Note that Xray is already on an untagged commit (aa6edf4, 6 commits after v1.8.2), so I thought a pinned commit was acceptable.
For context, here's what I see in Russia: on my connections chrome currently fails everywhere, firefox works, qq works in some places. Same servers, only the fingerprint changed. tbh I didn't do massive research about that, so this may not be about the Chrome version itself.
I think I'll test chrome 155 fingerprint in the near future and compare it with 133 and if something changes, let you know
The author observed a combination of destination subnet/AS, TLS fingerprint and connection concurrency for the same SNI. Three simultaneous Chrome connections passed; four triggered a 120-second freeze.
So this does not require distinguishing uTLS from a real browser: genuine Chrome can be affected too. The exact thresholds may vary by ISP, region and time.
btw literally rn i tested MASQUE h3 and h2 to WARP on mobile net (YOTA mobile operator) and it... works. Didn't do any tests yet(except speedtest on h2, no issues), but still it's pretty impressive
Activity
Fangliding commentedon Oct 11, 2026
utls并没有 release (如果release了会自动更新)
并且 155 这个版本非常新 立刻迁移也不全是好事
FunLay123 commentedon Oct 11, 2026
@Fangliding Understood. Note that Xray is already on an untagged commit (aa6edf4, 6 commits after v1.8.2), so I thought a pinned commit was acceptable. Chrome 155 is the current stable channel, so most real Chrome traffic already looks like 155 and 133 is the outlier now.
RPRX commentedon Oct 12, 2026
等下次发版前(或许两周后)uTLS 还没 release 新版本的话就加吧
Fangliding commentedon Oct 12, 2026
用 pinned commit 是异常情况 因为我在 utls 加了 ECH 的 ALPN 伪装后也不能催他们发版 所以xray这边只好指定commit以实装这个功能
这是说不准的 因为大量的其他使用 chromium 的框架(如 electron)和使用 chromium 内核还未同步上游浏览器都会发出旧的指纹 所谓 chrome 133 是因为 133 更改了指纹 实际使用它的版本 是 133~154 不要觉得它很远古
FunLay123 commentedon Oct 13, 2026
@Fangliding fair. I haven't thought about that
For context, here's what I see in Russia: on my connections chrome currently fails everywhere, firefox works, qq works in some places. Same servers, only the fingerprint changed. tbh I didn't do massive research about that, so this may not be about the Chrome version itself.
I think I'll test chrome 155 fingerprint in the near future and compare it with 133 and if something changes, let you know
FunLay123 commentedon Oct 13, 2026
@Fangliding
@RPRX
Tested on Yota mobile → 94.249.187.12:443 using siberian-check with uTLS ff1b50fbbe9a:
One run per fingerprint. Between tests, I waited 130 seconds and toggled airplane mode.
RPRX commentedon Oct 13, 2026
Chrome 133 指纹早就被 TSPU 针对了,等 Xray-core 实载 Chrome 155 指纹后看看它多久会被针对Fangliding commentedon Oct 13, 2026
chrome 133 就是chrome指纹 它被拦那chrome也上不了网 要么就是utls有鹦鹉特征能精确和浏览器区分
RPRX commentedon Oct 13, 2026
@Fangliding 你猜对了,TSPU 就是限制了 Chrome 133 指纹的连接数,
有时候更狠点确实是 Chrome 也上不了外网,真的假的都一起 banFunLay123 commentedon Oct 13, 2026
This was reproduced with real Google Chrome, not just uTLS:
https://habr.com/ru/articles/1044396/
The author observed a combination of destination subnet/AS, TLS fingerprint and connection concurrency for the same SNI. Three simultaneous Chrome connections passed; four triggered a 120-second freeze.
So this does not require distinguishing uTLS from a real browser: genuine Chrome can be affected too. The exact thresholds may vary by ISP, region and time.
btw literally rn i tested MASQUE h3 and h2 to WARP on mobile net (YOTA mobile operator) and it... works. Didn't do any tests yet(except speedtest on h2, no issues), but still it's pretty impressive
Fangliding commentedon Oct 13, 2026
如果 masque 可以工作 那么 xhttp3 或者 hysteria 大概率也可以
FunLay123 commentedon Oct 13, 2026
@Fangliding not sure. I was using Hysteria2 with h3 like a month ago or something and it worked fine
FunLay123 commentedon Oct 13, 2026
Well, i don't think QUIC is blocked for me:/
RPRX commentedon Oct 14, 2026
#7144 (reply in thread)
RPRX commentedon Oct 14, 2026
https://t.me/projectXtls/3583
Bump uTLS to ff1b50f, add hellochrome_155 fingerprint
Bump uTLS to ff1b50f, add hellochrome_155 fingerprint
maoxikun commentedon Oct 23, 2026
ech 是不是跟safari不太兼容,同时配置 "fingerprint": "safari" 和 ech(reality正常) 在不配置 alpn 和 "alpn": [h2"] 情况报错, "alpn": [h3"] 则正常
[Info] [2581954356] transport/internet/splithttp: failed to GET https://xxx.com/zzzz/ > Get "https://xxx.com/zzzz/fa106b9a-c1ee-4ded-9c89-9f4582b144ea": tls: malformed outer client helloFunLay123 commentedon Oct 24, 2026
@RPRX
Hi! Any plans about updating utls fingerprint? I think it would be a good addition for the soon release
Bump uTLS to ff1b50f, add hellochrome_155 fingerprint