YouTube Music

[ShiveringSheo]

Trying to reach the YouTube music website (Https://music.youtube.com) gives me an error that says:
"Sorry, YouTube Music is not optimized for your browser. Check for updates or try Google Chrome."
This appears on any browser (even Chrome) and on the PWA (Progressive Web App) version of YouTube Music as well. Getting over that initial error with another vpn and then switching to MHRV-RS keeps things working however, so the service works fine except for that initial warning that prevents use. Is there any way to bypass this without needing to switch VPNs every time the page refreshes?

[therealaleph]

Reviewed via Anthropic Claude.

@ShiveringSheo — YouTube Music is not optimized for your browser is YouTube Music's User-Agent check. The page loads but Music's player rejects the UA seen at the upstream. Two paths:

1. youtube_via_relay: false in config.json — sends music.youtube.com via SNI rewrite tunnel (preserves browser UA, since Apps Script isn't in the path for that hostname). Caveat: subject to YouTube's restricted-mode side effects on the SNI=www.google.com edge.

2. Pin music.youtube.com to passthrough_hosts:

"passthrough_hosts": ["music.youtube.com"]

Bypasses MITM entirely for that one host — raw TCP via SNI rewrite. Safest for UA-strict sites.

Either should fix the message. The Apps Script relay path doesn't work for Music because YouTube's Music player has stricter UA gating than the main YouTube player (which we've been working around via PR #977).

Leaving open until you confirm the workaround works.

[ShiveringSheo]

@therealaleph unfortunately turning off the relay on desktop tells me that it's unavailable in my area and on android redirects me to the app store page for the YouTube Music app.

The passthrough method doesn't even load the webpage, giving the error "ERR_SSL_PROTOCOL_ERROR" instead

[therealaleph]

@ShiveringSheo — that's actually two separate signals:

Desktop with youtube_via_relay: false → "unavailable in my area" page is YouTube Music's geo-block. With relay off, music.youtube.com goes via SNI rewrite to Google's GFE — but the GFE returns the response keyed off the request's apparent origin which now matches your IP (because you've routed direct, not via Apps Script). YouTube Music isn't licensed in Iran, so the GFE serves the "not available in your country" page when it sees an Iran IP.

Android with youtube_via_relay: false → "redirects to app store" is the same geo-block, just rendered as the install-the-app upsell instead of the desktop unavailability page.

Both are YouTube Music's licensing geo-fence, not a routing/UA issue. With youtube_via_relay: true, requests come from Apps Script's Google datacenter IP (US) and YouTube Music allows the request — which is why that mode shows the warning instead of the geo-block.

This means YouTube Music specifically needs the Apps Script relay path to bypass the Iran geo-fence. The remaining question is the UA-mismatch warning when relayed. Two paths to fix:

1. passthrough_hosts: ["music.youtube.com"] — bypasses MITM but still routes via SNI rewrite. Doesn't help here since the SNI-rewrite path is what's hitting the geo-block.

2. Route via exit-node (Deno Deploy / Replit / VPS) — exit-node fetches from a different country (US/EU/etc), YouTube Music sees that IP. Add to config.json:

   "exit_node": {
     "enabled": true,
     "relay_url": "https://your-exit-node",
     "psk": "<secret>",
     "mode": "selective",
     "hosts": ["music.youtube.com"]
   }

Option 2 should give you both: bypass geo-fence (exit-node IP looks like a normal residential US/EU IP) AND avoid the UA mismatch (exit-node uses real fetch, not Apps Script's UrlFetchApp).

Closing — let me know if option 2 works.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}