Skip to content

Commit aba5393

Browse files
therealalephclaude
andcommitted
v1.7.6: revert googlevideo.com SNI rewrite (#275, #281)
v1.7.4 added googlevideo.com to SNI_REWRITE_SUFFIXES on the theory that video chunks should bypass the Apps Script relay. Multiple users (#275 amirabbas117, #281 mrerf) reported total YouTube breakage on v1.7.4: SNI-rewriting googlevideo.com:443 to a GFE IP returned TLS handshake failure / wrong-cert error. Root cause: googlevideo.com is served by Google's separate "EVA" edge IPs, not the regular GFE IPs that the user's `google_ip` typically points at. The SNI-rewrite tunnel TLS handshake against a GFE IP for googlevideo.com SNI fails because the GFE IP doesn't hold a googlevideo.com cert. Pre-v1.7.4 behaviour restored: video chunks fall through to the Apps Script relay path. Slower but reliable on every GFE IP. The other v1.7.4 youtube_via_relay carve-out fixes (ytimg.com correctly stays on SNI rewrite, youtubei.googleapis.com correctly goes through relay) remain intact — those were a separate improvement and still correct. Future: if we want direct googlevideo.com routing, it needs a separate `eva_edge_ip` config knob — users can populate from their own EVA scan, defaulting to "use relay" if not configured. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1 parent 0bc7137 commit aba5393

5 files changed

Lines changed: 36 additions & 30 deletions

File tree

Cargo.lock

Lines changed: 1 addition & 1 deletion
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

Cargo.toml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
[package]
22
name = "mhrv-rs"
3-
version = "1.7.5"
3+
version = "1.7.6"
44
edition = "2021"
55
description = "Rust port of MasterHttpRelayVPN -- DPI bypass via Google Apps Script relay with domain fronting"
66
license = "MIT"

android/app/build.gradle.kts

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -14,8 +14,8 @@ android {
1414
applicationId = "com.therealaleph.mhrv"
1515
minSdk = 24 // Android 7.0 — covers 99%+ of live devices.
1616
targetSdk = 34
17-
versionCode = 150
18-
versionName = "1.7.5"
17+
versionCode = 151
18+
versionName = "1.7.6"
1919

2020
// Ship all four mainstream Android ABIs:
2121
// - arm64-v8a — 95%+ of real-world Android phones since 2019

docs/changelog/v1.7.6.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
<!-- see docs/changelog/v1.1.0.md for the file format: Persian, then `---`, then English. -->
2+
• Revert غلط v1.7.4 برای `googlevideo.com` ([#275](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/issues/275)، [#281](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/issues/281)): v1.7.4 تلاش کرد `googlevideo.com` رو به لیست SNI rewrite اضافه کنه به این تئوری که chunk‌های ویدیو باید از Apps Script relay دور بزنن. **چندین کاربر گزارش دادن که v1.7.4 YouTube رو کاملاً شکست داد** — علت: `googlevideo.com` توسط edge IP‌های جدا "EVA" گوگل serve می‌شه، نه GFE IP عادی که `google_ip` کاربر معمولاً به اون اشاره می‌کنه. SNI-rewrite کردن `googlevideo.com:443` به یه GFE IP باعث TLS handshake failure یا wrong-cert error برای اون کاربرها شد. **رفتار قبل از v1.7.4 برگشته** (chunk‌های ویدیو از مسیر Apps Script relay می‌رن — کندتر ولی روی هر GFE IP قابل اعتماد). تغییرات `youtube_via_relay` carve-out از v1.7.4 (که `ytimg.com` رو از relay پاک کرد) دست نخورده — اون regression جدا بود و درست شده باقی مونده. اگه کاربری در آینده EVA edge IP خودش رو پیکربندی بکنه، یه knob مجزا اضافه می‌کنیم.
3+
---
4+
• Revert v1.7.4 `googlevideo.com` SNI rewrite ([#275](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/issues/275), [#281](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/issues/281)): v1.7.4 added `googlevideo.com` to the SNI rewrite list on the theory that video chunks should bypass the Apps Script relay. **Multiple users reported v1.7.4 broke YouTube entirely** — root cause: `googlevideo.com` is served by Google's separate "EVA" edge IPs, not the regular GFE IPs that `google_ip` typically points at. SNI-rewriting `googlevideo.com:443` to a GFE IP got TLS handshake failures or wrong-cert errors for those users. **Pre-v1.7.4 behaviour is restored** (video chunks go via the Apps Script relay path — slower but reliable on every GFE IP). The other v1.7.4 `youtube_via_relay` carve-out changes (which removed `ytimg.com` from the carve-out) are intact — those were a separate fix that's still correct. If a user ever wants direct googlevideo.com routing, that needs a separate config knob letting them specify their EVA edge IP independently.

src/proxy_server.rs

Lines changed: 28 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -47,18 +47,18 @@ const SNI_REWRITE_SUFFIXES: &[&str] = &[
4747
"youtu.be",
4848
"youtube-nocookie.com",
4949
"ytimg.com",
50-
// YouTube video CDN. Issue #275: a user reported that with
51-
// `youtube_via_relay = true`, every video chunk was traversing the
52-
// Apps Script relay and a single chunk timeout aborted playback —
53-
// because `googlevideo.com` was not on this list, all chunks
54-
// fell through to the relay path. Adding it here keeps video
55-
// bytes on the direct GFE tunnel even when the relay flag is on
56-
// (the YOUTUBE_RELAY_HOSTS carve-out below excludes only the API
57-
// / HTML surfaces, not the CDN). The chunks are unauthenticated
58-
// bytes anyway — there's no Restricted Mode logic on the CDN, so
59-
// routing them through Apps Script gains nothing and costs the
60-
// 6-minute Apps Script execution cap on long videos.
61-
"googlevideo.com",
50+
// NOTE on `googlevideo.com`: v1.7.4 (#275) added this here on the
51+
// theory that video chunks should bypass the Apps Script relay.
52+
// **Reverted in v1.7.6** — multiple users (#275 amirabbas117, #281
53+
// mrerf) reported total YouTube breakage after v1.7.4. Root cause
54+
// is that googlevideo.com is served by Google's separate "EVA"
55+
// edge IPs, not the regular GFE IPs that the user's `google_ip`
56+
// typically points at. SNI-rewriting `googlevideo.com:443` to a
57+
// GFE IP got TLS handshake / wrong-cert errors for those users.
58+
// Pre-v1.7.4 behaviour (chunks via the Apps Script relay path —
59+
// slow but reliable on every GFE IP) is restored. If we ever want
60+
// direct googlevideo.com routing, it needs a separate config knob
61+
// that lets users specify their EVA edge IP independently.
6262
// Google Video Transport CDN — YouTube video chunks, Chrome
6363
// auto-updates, Google Play Store downloads. The single biggest
6464
// gap vs the upstream Python port: without these in the list
@@ -2719,13 +2719,21 @@ mod tests {
27192719
assert!(should_use_sni_rewrite(&hosts, "www.google.com", 443, false));
27202720
assert!(should_use_sni_rewrite(
27212721
&hosts,
2722-
"rr1---sn-abc.googlevideo.com",
2722+
"youtubei.googleapis.com",
27232723
443,
27242724
false
27252725
));
2726-
assert!(should_use_sni_rewrite(
2726+
2727+
// googlevideo.com is INTENTIONALLY NOT in SNI_REWRITE_SUFFIXES
2728+
// — see the long note at the top of the SNI list. v1.7.4 tried
2729+
// adding it; reverted in v1.7.6 after user reports of total
2730+
// YouTube breakage. If the project ever ships an EVA-edge-IP
2731+
// config knob, this assertion can flip. Until then, video
2732+
// chunks correctly fall through to the Apps Script relay path
2733+
// and this assertion guards against a regression.
2734+
assert!(!should_use_sni_rewrite(
27272735
&hosts,
2728-
"youtubei.googleapis.com",
2736+
"rr1---sn-abc.googlevideo.com",
27292737
443,
27302738
false
27312739
));
@@ -2746,18 +2754,12 @@ mod tests {
27462754
true
27472755
));
27482756

2749-
// Flag on: video / image / channel-asset CDNs STAY on SNI
2750-
// rewrite. The pre-#275 implementation broke playback by
2751-
// routing googlevideo.com through Apps Script (it wasn't even
2752-
// in the SNI list before #275, so it always went via relay)
2753-
// and routed ytimg.com through the relay too.
2757+
// Flag on: image / channel-asset CDNs STAY on SNI rewrite. Pre-#275
2758+
// ytimg.com was incorrectly carved out alongside the API surfaces.
2759+
// googlevideo.com still goes through the relay path (not in the
2760+
// SNI list at all — see note above the SNI_REWRITE_SUFFIXES
2761+
// entries) so the same flag-on assertion isn't applicable to it.
27542762
assert!(should_use_sni_rewrite(&hosts, "i.ytimg.com", 443, true));
2755-
assert!(should_use_sni_rewrite(
2756-
&hosts,
2757-
"rr1---sn-abc.googlevideo.com",
2758-
443,
2759-
true
2760-
));
27612763
assert!(should_use_sni_rewrite(&hosts, "yt3.ggpht.com", 443, true));
27622764

27632765
// Flag on: non-YouTube Google suffixes are unaffected. Note

0 commit comments

Comments
 (0)