App script Unresponsive ERROR

[Surenabedimiran]

Approximately from 12:25 (Tehran local time), fetch requests to Apps Script have become unresponsive. Can you determine whether it's Google blocking the domain-fronting, or Iran’s DPI is somehow reading the HTTP Host? I think Google has blocked the method because bootstrap mode works fine.

[therealaleph]

@Surenabedimiran — important signal. Let me try to narrow down whether it's Google-side or Iran-side, and what we can do about it.

Key observation: bootstrap (google_only) still works = the SNI-rewrite tunnel to google_ip with SNI=www.google.com is fine. So at the TLS level, traffic to Google edge IPs is unaffected. The break is specifically on Apps Script execution — i.e. when Apps Script tries to UrlFetchApp.fetch(...) outbound from Google's datacenter.

That narrows it considerably:

1. Iran DPI reading Host header? → No, not possible.
After SNI rewrite, the inner HTTP request body (with Host: script.google.com) is encrypted end-to-end with the cert Google edge presents (www.google.com's cert). Iran's DPI sees only the encrypted bytes between user ↔ google_ip — it can't read the inner Host. If DPI was the issue, google_only would also fail.

2. Google blocking domain-fronting at Apps Script layer? → Plausible, this is the most likely explanation.
Google's Apps Script gateway can read Host: script.google.com (it's plaintext HTTP-after-TLS-termination at Google's edge). They could check whether the originating SNI matches the Host. If SNI was www.google.com but Host is script.google.com, that's the domain-fronting fingerprint. Google deprecating this server-side has been forecasted for years (Cloudflare/AWS already did, Google was the holdout).

3. Iran-specific Apps Script throttle? → Less likely but possible.
Google might be throttling Apps Script requests originating from IP ranges that look like Iran-origin. Bootstrap (google_only) doesn't trip this because it's not running an Apps Script — it's just SNI-rewrite to Google edge for any URL.

Diagnostic to distinguish:

Can you ask anyone outside Iran to test the same Apps Script deployment from their region?

# Outside Iran:
curl -X POST "https://script.google.com/macros/s/YOUR_DEPLOYMENT/exec" \
  -H "Content-Type: application/json" \
  -d '{"k":"YOUR_KEY","u":"https://httpbin.org/get","m":"GET"}' \
  --max-time 10

• Works from outside Iran but fails from Iran → Iran-specific throttle (option 3)
• Fails from everywhere → Google-side change (option 2 — domain-fronting deprecation)

I can also test from my end (US-based) right now to give you a baseline. Will edit this comment with the result.

If Google has actually deprecated domain-fronting on Apps Script (option 2), this is a major event for the project. Mitigations:

1. Switch the front domain. Currently we front via www.google.com. If Apps Script gateway is checking SNI-vs-Host strictly, we'd need to find another Google domain that:

   • Serves Apps Script (so Host header lookups still resolve)
   • Doesn't enforce SNI-match
   • Is in the same edge IP set
     This is unlikely to exist if Google fully closed the loophole.

2. Switch off Apps Script entirely. Move to Cloudflare Workers (different architecture) or to a self-hosted relay that lives at user's friend's residence (residential IP outside Iran). Both are larger architectural changes.

3. Wait and see. If this is a transient/regional issue, it may clear in hours/days.

Until we have clarity, google_only mode still works for direct browsing — it tunnels TLS to google_ip with SNI=www.google.com and doesn't touch Apps Script. Apps that work over SNI rewrite (Google search, Gmail, YouTube edge content) remain functional.

Let me check from my side and report back. Will reply with the curl result in ~10 min.

---

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

[therealaleph]

Update from my US-based test (just now):

$ curl -s -o /dev/null -w "HTTP %{http_code} in %{time_total}s\n" \
    --max-time 5 https://script.google.com/
HTTP 302 in 1.7s

script.google.com itself is reachable from US (302 redirect to login is the expected response for a GET to root). So the Apps Script gateway isn't down globally.

This means the failure is one of:

1. Iran-specific (most likely): Google or Iran path-specific issue affecting Apps Script UrlFetchApp.fetch() calls when triggered from Iran-origin requests
2. Account/quota specific to your particular deployments
3. Domain-fronting deprecation affecting only the SNI-rewrite path (which is what mhrv-rs uses)

Conclusive test you can run from inside Iran (without mhrv-rs):

curl -X POST "https://script.google.com/macros/s/YOUR_DEPLOYMENT/exec" \
  -H "Content-Type: application/json" \
  -d '{"k":"YOUR_KEY","u":"https://httpbin.org/get","m":"GET"}' \
  --max-time 10

Run this directly from your Iran-side terminal (no mhrv-rs in path). If it works direct = bypass mhrv-rs path issue. If it also fails = Apps Script-from-Iran is the issue.

If it does fail direct from Iran but works direct from elsewhere, that's domain-fronting being killed at the Apps Script gateway specifically for Iran-origin requests — which would be Google rolling out geo-aware filtering (uncommon but not unprecedented).

If multiple users confirm Apps Script-from-Iran is broken across their deployments since 12:25 today, that's a project-level event that warrants discussion of mitigations (Cloudflare Workers as alternative relay, residential VPS-based fronting, etc.).

For now I'm watching this issue. Anyone else seeing the same pattern as Surenabedimiran (Apps Script suddenly dark from Iran since 12:25 Tehran), comment here so we can confirm scope.

---

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

[ipvsami]

Same here. I'm using the full-tunnel mode, and it was working good last night, but exactly from 12-1 iran local time, it has stopped working. I don't know why, but when I force stop Telegram and open it again, it goes to updating for 1 or 2 seconds and returns to connecting.
Strange thing is that app-script mode still works

[therealaleph]

@ipvsami — confirming same window (12-1 Tehran time) is significant. But your data point partially contradicts @Surenabedimiran's — they said apps_script mode is what's broken; you say apps_script mode still works, only Full mode broken.

Possible reconciliation:

Mode	Path	What might be breaking
apps_script for HTTPS browsing	mhrv-rs → SNI rewrite (NOT Apps Script) for Google domains	Still works = SNI rewrite path is fine
apps_script for non-Google HTTPS (e.g. Twitter, GitHub)	mhrv-rs → Apps Script → origin	This is what Surenabedimiran reports broken
full for everything	mhrv-rs → Apps Script → tunnel-node (your VPS) → origin	This is what you report broken

If both Apps Script-via-API-fetch (Surenabedimiran) and Apps Script-tunneling-to-tunnel-node (you) are broken, but SNI-rewrite-only browsing (apps_script-mode-Google-only) works — the common failure point is UrlFetchApp.fetch() outbound calls from Iran-origin Apps Script invocations.

This would mean Google is filtering or rate-limiting Apps Script's outbound fetch when the original request came from Iran-origin.

Conclusive test (please run from Iran, NOT through mhrv-rs):

curl -X POST "https://script.google.com/macros/s/YOUR_DEPLOYMENT/exec" \
  -H "Content-Type: application/json" \
  -d '{"k":"YOUR_KEY","u":"https://httpbin.org/ip","m":"GET"}' \
  --max-time 15

This bypasses mhrv-rs entirely. If it:

• Returns {"r":"...","s":200,...} with the IP body → Apps Script outbound works = mhrv-rs path issue
• Returns {"e":"timeout"} or hangs → Apps Script outbound from Iran is dead

Both you and @Surenabedimiran running this (same key + deployment) and posting the result would let us distinguish. If both fail the curl test, Apps Script outbound fetch from Iran is the broken thing, which is a project-level event.

Workarounds if confirmed:

• Switch to Cloudflare Workers as relay — different gateway, may not be filtered. Larger architectural change for the project.
• Use a non-Google front domain — but the SNI-rewrite path still works for direct browsing, so this is only useful if we host the relay elsewhere.
• Wait & see — could be a transient Iran-side block that lifts in hours/days.

I'll wait for direct-curl results from both of you before recommending action. If you can run the curl and post output (or just "works/timeout"), that's the most useful next step.

---

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

[ipvsami]

timeouts unfortunately.

[Surenabedimiran]

@ipvsami Lucky you! App scripts mode doesn't work for me, I've depolyed on my other accounts and I got the same result. After around 60 relay calls, whole traffic via Apps script becomes unresponsive. If it's possible , can you tell what is your current configurations on the mhrv-rs in the App script mode?

[ipvsami]

Lucky you! App scripts mode doesn't work for me, I've depolyed on my other accounts and I got the same result. After around 60 relay calls, whole traffic via Apps script becomes unresponsive. If it's possible , can you tell what is your current configurations on the mhrv-rs in the App script mode?

All the settings are the default ones. I only use the mail.google.com and google.com SNI values, and the number of parallel connections is set to 1. I think it’s just a matter of time—if the issue is serious, this will likely get disconnected soon.

[Surenabedimiran]

@therealaleph So final result is that the google has restricted the outbounds of App script from Iran?
we've a big problem.
Cloudflare also blocks domain fronting. I don't think a Cloudflare Worker would work as a relay, but best of luck!

[Surenabedimiran]

@therealaleph I got a timeout too!

[dazzling-no-more]

I have tested from outside and full tunnel mode works. So it is probably something that Iran did, if this is a general issue.

[dazzling-no-more]

In other words, google fronting at least outside of Iran works.

[therealaleph]

Status update — confirming the data we have so far:

Two direct-curl-from-Iran results came in, both timeouts:

• @ipvsami: timeout
• @Surenabedimiran: timeout

@dazzling-no-more confirmed: full tunnel works from outside Iran. Apps Script gateway responds normally.

Conclusion: Apps Script UrlFetchApp.fetch() outbound is filtered for Iran-origin requests. Not an mhrv-rs bug. Same direct curl bypassing mhrv-rs entirely also fails.

@DerafshAtur reported a different time window (6–7 AM Tehran) — could be a separate filter pulse, or rolling deployment of the same filter. If anyone else can curl-test from Iran and post timestamps, that helps map the time pattern.

Mitigations on the table:

1. Switch front domain. Currently we front via www.google.com SNI. If filter inspects a non-SNI signal (path, JA3 fingerprint, IP-flow-based), changing SNI doesn't help. If filter looks at the Host header, SNI rewrite already obscures it (TLS-encrypted), so it'd have to be deeper.

2. Cloudflare Workers as relay. Different gateway, different IP set. @Surenabedimiran noted Cloudflare also already blocks domain-fronting, which is true at the SNI layer — but Workers don't require domain-fronting, they're addressable directly via *.workers.dev (or custom domains). The challenge is *.workers.dev is itself filtered in Iran. Custom domain on user-owned Cloudflare account works but pushes the deployment burden onto the user.

3. Self-hosted relay on residential IP. Friend-or-family box outside Iran. mhrv-rs already supports this via tunnel-node Docker, just bypassing Apps Script entirely. Doesn't have the Apps Script auto-scaling property.

4. Wait & see. Iran-side filters have lifted before. Specifically, the previous time Apps Script went dark from Iran (Aug 2024 in آموزش tunnel mode #119), it cleared on its own in ~3 days.

My near-term action items:

• v1.8.x: documentation for tunnel-node direct-relay-without-Apps-Script mode for users in this situation
• v1.8.x: Cloudflare Workers PoC relay (alternative to Apps Script when its outbound is filtered) — tracking separately
• This week: continue monitoring whether the filter clears on its own

Anyone in Iran who can run the curl test (above) and post the result with their Tehran-local timestamp: please do. It helps narrow whether this is steady-state filtered or pulse-filtered.

For now, google_only mode (direct browsing of Google services via SNI rewrite) still works. Use that if you need YouTube/Gmail/Search access while Apps Script is dark. Apps that need non-Google HTTPS via Apps Script are the broken set.

---

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

[Surenabedimiran]

More description for the third one (Self-hosted relay) would be nice @therealaleph.