uTLS: bump to 6ebdceb (Chrome 155), register hellochrome_155

[izislesar]

Fixes #7131

What

• Bump refraction-networking/utls from aa6edf4 to 6ebdceb (2026-10-06, no tagged release yet — same pinned-commit pattern as the current aa6edf4 pin) and add "hellochrome_155" to ModernFingerprints.
• HelloChrome_Auto resolves to HelloChrome_155 in uTLS 6ebdceb, so the default chrome preset (also used by ECH) automatically follows the current stable Chrome.

Rationale

Per @RPRX's comment on #7131: if uTLS has not released a new tagged version by the next Xray release, bump it. As of now (2026-10-13) there is still no uTLS release containing 6ebdceb, so I'd like to land this before the next release window.

Note (per the issue): Chrome 155's ClientHello replaces the one introduced in 133; frames still on 133–154-class Chromium (e.g. Electron not yet rebased) will still emit the old Fingerprint, so hellochrome_133/hellochrome_120 remain available.

JA4 comparison (from #7131, verified by reporter)

Source	JA4
Xray 26.10.10 chrome (utls aa6edf4)	t13d1516h2_8daaf6152771_d8a2da3f94cd
Xray + utls 6ebdceb (this PR)	t13d1517h2_8daaf6152771_cb7bf5808d99
Google Chrome 155 (Linux, stable)	t13d1517h2_8daaf6152771_cb7bf5808d99

Verification

• go build ./... — OK
• go test ./transport/internet/... ./infra/conf/... — OK (geodata cache present locally)
• go run ./infra/vformat/main.go -mode check -pwd ./ — passes
• checked that 6ebdceb is strictly ahead of the current pin aa6edf4 (0 commits behind), so ECH ALPN work is retained.

[patterniha]

why 6ebdceb2607e commit and not latest commit?

[Fangliding]

这么急干什么 如果release了肯定是优先用正常版本号的啊 就算没有也是放两周后的最新commit

[RPRX]

先留着吧，感觉 uTLS 不会 tag 的

[Fangliding]

不会tag也是取两周后的版本啊

[RPRX]

@patterniha 话说你的 NG 是不是已经加了 MASQUE？可以去给 v2rayNG PR 一下

[patterniha]

@patternihaBy the way, did you add MASQUE to your NG?You can submit a PR to v2rayNG.

Honestly, I’m not really interested in UI work. Adding such elements without AI is extremely time-consuming—especially for me, since I’m not familiar with Android UI.
I still hope ...

Anyway, for warp I still prefer aether-core, which includes key retrieval, scanning, and connectivity—all in a single package.

[patterniha]

Off Topic:

Currently, the GFW is implementing a whitelist for Cloudflare; however, the "cloudflare-ech.com" domain is currently included in that whitelist, so most users are connecting to Cloudflare using ECH.
It is likely that ECH will soon be removed from the whitelist.
None of the SNI-spoofing methods currently implemented in Sing-box are working.
Yesterday, I successfully tested an innovative SNI-spoofing method, and I will release it once ECH is blocked.

[izislesar]

Got it! I'll wait for the official uTLS release with commit 6ebdceb and then reopen this PR. Thanks for the guidance! 🙏

[RPRX]

@izislesar 先 rebase，然后把 uTLS commit id 改成 refraction-networking/utls@ff1b50f 吧

[izislesar]

Rebased onto latest main and updated the uTLS pin to ff1b50f as requested

[Fangliding]

为什么test失败了

[Meo597]

Test_ListenXHAndDial_QUIC
Test_listenHTTPUpgradeAndDial_TLS
panic: test timed

[izislesar]

@Fangliding The test failures are caused by a deadlock in uTLS itself, not by this PR. Test_ListenXHAndDial_QUIC hangs because the Go 1.26 QUIC rework synced into uTLS (63aeec73, present in both 6ebdceb and ff1b50f) left UQUICConn broken — see refraction-networking/utls#421, with fixes in refraction-networking/utls#424 and refraction-networking/utls#425 (not yet merged).

Verified locally:

• with the current aa6edf4 pin, Test_ListenXHAndDial_QUIC passes in ~1s
• with 6ebdceb or ff1b50f it deadlocks 100% of the time (the uTLS client goroutine waits forever in quicWaitForSignal while quic-go has already torn down the connection)
• bumping the quic-go fork (v0.61 → v0.62/v0.63 mod-rename branches) doesn't help
• with uTLS patched per utls#425 (tested against a build of ff1b50f + the fix, quic-go left untouched at v0.61.1-184d081) the test passes

Note: Test_listenHTTPUpgradeAndDial_TLS actually passes — it only appears in the goroutine dump of the test-timeout panic; the only hanging test is the QUIC one (on all three OSes).

So this PR just surfaces the upstream bug. Options: wait for utls to merge #424/#425 and re-pin, or land this as-is knowing QUIC chrome-parrot is broken until then. @RPRX which do you prefer?

[izislesar]

sorry guys im kinda bad in english and chinese so i use AI to write comments

[RPRX]

看来今天的新版本无缘新指纹了