Skip to content

Bump uTLS: chrome fingerprint is still Chrome 133 #7131

Open

Description

@FunLay123

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.

Captured ClientHellos (JA4):

  • Xray 26.10.10 chrome: t13d1516h2_8daaf6152771_d8a2da3f94cd
  • Xray + utls 6ebdceb: t13d1517h2_8daaf6152771_cb7bf5808d99
  • 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.

Activity

  1. Fangliding commented on Oct 11, 2026

    @Fangliding
    Member

    utls并没有 release (如果release了会自动更新)
    并且 155 这个版本非常新 立刻迁移也不全是好事

  2. FunLay123 commented on Oct 11, 2026

    @FunLay123
    ContributorAuthor

    @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. reopened this on Oct 12, 2026
  4. RPRX commented on Oct 12, 2026

    @RPRX
    Member

    等下次发版前(或许两周后)uTLS 还没 release 新版本的话就加吧

  5. Fangliding commented on Oct 12, 2026

    @Fangliding
    Member

    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.

    用 pinned commit 是异常情况 因为我在 utls 加了 ECH 的 ALPN 伪装后也不能催他们发版 所以xray这边只好指定commit以实装这个功能

    Chrome 155 is the current stable channel, so most real Chrome traffic already looks like 155 and 133 is the outlier now.

    这是说不准的 因为大量的其他使用 chromium 的框架(如 electron)和使用 chromium 内核还未同步上游浏览器都会发出旧的指纹 所谓 chrome 133 是因为 133 更改了指纹 实际使用它的版本 是 133~154 不要觉得它很远古

  6. FunLay123 commented on Oct 13, 2026

    @FunLay123
    ContributorAuthor

    @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

  7. FunLay123 commented on Oct 13, 2026

    @FunLay123
    ContributorAuthor

    @Fangliding
    @RPRX
    Tested on Yota mobile → 94.249.187.12:443 using siberian-check with uTLS ff1b50fbbe9a:

    Fingerprint Siberian restriction Time
    Chrome 133 Yes — TLS handshake timeout 8426 ms
    Chrome 155 No 733 ms
    Firefox 148 No 680 ms
    QQ 11.1 No 726 ms

    One run per fingerprint. Between tests, I waited 130 seconds and toggled airplane mode.

  8. RPRX commented on Oct 13, 2026

    @RPRX
    Member

    Chrome 133 指纹早就被 TSPU 针对了,等 Xray-core 实载 Chrome 155 指纹后看看它多久会被针对

  9. Fangliding commented on Oct 13, 2026

    @Fangliding
    Member

    chrome 133 就是chrome指纹 它被拦那chrome也上不了网 要么就是utls有鹦鹉特征能精确和浏览器区分

  10. RPRX commented on Oct 13, 2026

    @RPRX
    Member

    @Fangliding 你猜对了,TSPU 就是限制了 Chrome 133 指纹的连接数,有时候更狠点确实是 Chrome 也上不了外网,真的假的都一起 ban

  11. FunLay123 commented on Oct 13, 2026

    @FunLay123
    ContributorAuthor

    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

  12. Fangliding commented on Oct 13, 2026

    @Fangliding
    Member

    如果 masque 可以工作 那么 xhttp3 或者 hysteria 大概率也可以

  13. FunLay123 commented on Oct 13, 2026

    @FunLay123
    ContributorAuthor

    @Fangliding not sure. I was using Hysteria2 with h3 like a month ago or something and it worked fine

  14. FunLay123 commented on Oct 13, 2026

    @FunLay123
    ContributorAuthor

    Well, i don't think QUIC is blocked for me:/

  15. RPRX commented on Oct 14, 2026

    @RPRX
    Member
  16. RPRX commented on Oct 14, 2026

    @RPRX
    Member
  17. added 2 commits that reference this issue on Oct 16, 2026
    e5a6911
    90ed7c8
  18. maoxikun commented on Oct 23, 2026

    @maoxikun
    Contributor

    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 hello

  19. FunLay123 commented on Oct 24, 2026

    @FunLay123
    ContributorAuthor

    @RPRX
    Hi! Any plans about updating utls fingerprint? I think it would be a good addition for the soon release

  20. added a commit that references this issue on Oct 29, 2026
    ad8f736
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions