mirror of
https://github.com/therealaleph/MasterHttpRelayVPN-RUST.git
synced 2026-05-19 08:04:39 +03:00
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>
This commit is contained in:
Generated
+1
-1
@@ -2222,7 +2222,7 @@ dependencies = [
|
|||||||
|
|
||||||
[[package]]
|
[[package]]
|
||||||
name = "mhrv-rs"
|
name = "mhrv-rs"
|
||||||
version = "1.7.5"
|
version = "1.7.6"
|
||||||
dependencies = [
|
dependencies = [
|
||||||
"base64 0.22.1",
|
"base64 0.22.1",
|
||||||
"bytes",
|
"bytes",
|
||||||
|
|||||||
+1
-1
@@ -1,6 +1,6 @@
|
|||||||
[package]
|
[package]
|
||||||
name = "mhrv-rs"
|
name = "mhrv-rs"
|
||||||
version = "1.7.5"
|
version = "1.7.6"
|
||||||
edition = "2021"
|
edition = "2021"
|
||||||
description = "Rust port of MasterHttpRelayVPN -- DPI bypass via Google Apps Script relay with domain fronting"
|
description = "Rust port of MasterHttpRelayVPN -- DPI bypass via Google Apps Script relay with domain fronting"
|
||||||
license = "MIT"
|
license = "MIT"
|
||||||
|
|||||||
@@ -14,8 +14,8 @@ android {
|
|||||||
applicationId = "com.therealaleph.mhrv"
|
applicationId = "com.therealaleph.mhrv"
|
||||||
minSdk = 24 // Android 7.0 — covers 99%+ of live devices.
|
minSdk = 24 // Android 7.0 — covers 99%+ of live devices.
|
||||||
targetSdk = 34
|
targetSdk = 34
|
||||||
versionCode = 150
|
versionCode = 151
|
||||||
versionName = "1.7.5"
|
versionName = "1.7.6"
|
||||||
|
|
||||||
// Ship all four mainstream Android ABIs:
|
// Ship all four mainstream Android ABIs:
|
||||||
// - arm64-v8a — 95%+ of real-world Android phones since 2019
|
// - arm64-v8a — 95%+ of real-world Android phones since 2019
|
||||||
|
|||||||
@@ -0,0 +1,4 @@
|
|||||||
|
<!-- see docs/changelog/v1.1.0.md for the file format: Persian, then `---`, then English. -->
|
||||||
|
• 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 مجزا اضافه میکنیم.
|
||||||
|
---
|
||||||
|
• 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.
|
||||||
+28
-26
@@ -47,18 +47,18 @@ const SNI_REWRITE_SUFFIXES: &[&str] = &[
|
|||||||
"youtu.be",
|
"youtu.be",
|
||||||
"youtube-nocookie.com",
|
"youtube-nocookie.com",
|
||||||
"ytimg.com",
|
"ytimg.com",
|
||||||
// YouTube video CDN. Issue #275: a user reported that with
|
// NOTE on `googlevideo.com`: v1.7.4 (#275) added this here on the
|
||||||
// `youtube_via_relay = true`, every video chunk was traversing the
|
// theory that video chunks should bypass the Apps Script relay.
|
||||||
// Apps Script relay and a single chunk timeout aborted playback —
|
// **Reverted in v1.7.6** — multiple users (#275 amirabbas117, #281
|
||||||
// because `googlevideo.com` was not on this list, all chunks
|
// mrerf) reported total YouTube breakage after v1.7.4. Root cause
|
||||||
// fell through to the relay path. Adding it here keeps video
|
// is that googlevideo.com is served by Google's separate "EVA"
|
||||||
// bytes on the direct GFE tunnel even when the relay flag is on
|
// edge IPs, not the regular GFE IPs that the user's `google_ip`
|
||||||
// (the YOUTUBE_RELAY_HOSTS carve-out below excludes only the API
|
// typically points at. SNI-rewriting `googlevideo.com:443` to a
|
||||||
// / HTML surfaces, not the CDN). The chunks are unauthenticated
|
// GFE IP got TLS handshake / wrong-cert errors for those users.
|
||||||
// bytes anyway — there's no Restricted Mode logic on the CDN, so
|
// Pre-v1.7.4 behaviour (chunks via the Apps Script relay path —
|
||||||
// routing them through Apps Script gains nothing and costs the
|
// slow but reliable on every GFE IP) is restored. If we ever want
|
||||||
// 6-minute Apps Script execution cap on long videos.
|
// direct googlevideo.com routing, it needs a separate config knob
|
||||||
"googlevideo.com",
|
// that lets users specify their EVA edge IP independently.
|
||||||
// Google Video Transport CDN — YouTube video chunks, Chrome
|
// Google Video Transport CDN — YouTube video chunks, Chrome
|
||||||
// auto-updates, Google Play Store downloads. The single biggest
|
// auto-updates, Google Play Store downloads. The single biggest
|
||||||
// gap vs the upstream Python port: without these in the list
|
// gap vs the upstream Python port: without these in the list
|
||||||
@@ -2719,13 +2719,21 @@ mod tests {
|
|||||||
assert!(should_use_sni_rewrite(&hosts, "www.google.com", 443, false));
|
assert!(should_use_sni_rewrite(&hosts, "www.google.com", 443, false));
|
||||||
assert!(should_use_sni_rewrite(
|
assert!(should_use_sni_rewrite(
|
||||||
&hosts,
|
&hosts,
|
||||||
"rr1---sn-abc.googlevideo.com",
|
"youtubei.googleapis.com",
|
||||||
443,
|
443,
|
||||||
false
|
false
|
||||||
));
|
));
|
||||||
assert!(should_use_sni_rewrite(
|
|
||||||
|
// googlevideo.com is INTENTIONALLY NOT in SNI_REWRITE_SUFFIXES
|
||||||
|
// — see the long note at the top of the SNI list. v1.7.4 tried
|
||||||
|
// adding it; reverted in v1.7.6 after user reports of total
|
||||||
|
// YouTube breakage. If the project ever ships an EVA-edge-IP
|
||||||
|
// config knob, this assertion can flip. Until then, video
|
||||||
|
// chunks correctly fall through to the Apps Script relay path
|
||||||
|
// and this assertion guards against a regression.
|
||||||
|
assert!(!should_use_sni_rewrite(
|
||||||
&hosts,
|
&hosts,
|
||||||
"youtubei.googleapis.com",
|
"rr1---sn-abc.googlevideo.com",
|
||||||
443,
|
443,
|
||||||
false
|
false
|
||||||
));
|
));
|
||||||
@@ -2746,18 +2754,12 @@ mod tests {
|
|||||||
true
|
true
|
||||||
));
|
));
|
||||||
|
|
||||||
// Flag on: video / image / channel-asset CDNs STAY on SNI
|
// Flag on: image / channel-asset CDNs STAY on SNI rewrite. Pre-#275
|
||||||
// rewrite. The pre-#275 implementation broke playback by
|
// ytimg.com was incorrectly carved out alongside the API surfaces.
|
||||||
// routing googlevideo.com through Apps Script (it wasn't even
|
// googlevideo.com still goes through the relay path (not in the
|
||||||
// in the SNI list before #275, so it always went via relay)
|
// SNI list at all — see note above the SNI_REWRITE_SUFFIXES
|
||||||
// and routed ytimg.com through the relay too.
|
// entries) so the same flag-on assertion isn't applicable to it.
|
||||||
assert!(should_use_sni_rewrite(&hosts, "i.ytimg.com", 443, true));
|
assert!(should_use_sni_rewrite(&hosts, "i.ytimg.com", 443, true));
|
||||||
assert!(should_use_sni_rewrite(
|
|
||||||
&hosts,
|
|
||||||
"rr1---sn-abc.googlevideo.com",
|
|
||||||
443,
|
|
||||||
true
|
|
||||||
));
|
|
||||||
assert!(should_use_sni_rewrite(&hosts, "yt3.ggpht.com", 443, true));
|
assert!(should_use_sni_rewrite(&hosts, "yt3.ggpht.com", 443, true));
|
||||||
|
|
||||||
// Flag on: non-YouTube Google suffixes are unaffected. Note
|
// Flag on: non-YouTube Google suffixes are unaffected. Note
|
||||||
|
|||||||
Reference in New Issue
Block a user