passthrough_hosts sends raw TCP without SNI rewrite — ERR_CONNECTION_RESET in Chrome vs direct ERR_CONNECTION_TIMED_OUT

[Montazeran8]

Environment

• mhrv-rs version: v1.9.14
• Mode: apps_script
• OS: Windows 10
• Browser: Google Chrome Version 145.0.7632.76 (Official Build) (64-bit)

Problem Description

I am using apps_script mode, and added deno.com, val.town, and fly.io to passthrough_hosts in order to bypass the relay for these sites while still having the benefit of SNI-rewrite to pass Iran's firewall.

My expectation was that mhrv-rs would still use the SNI-rewrite tunnel (like direct mode) for these hosts so the firewall sees SNI=www.google.com, but the traffic would not go through Apps Script relay.

What actually happens:
The traffic is sent as raw-tcp (direct) with the real SNI of the site (e.g. deno.com). The ISP firewall detects the real SNI, resets the connection, and the browser shows ERR_CONNECTION_RESET.

Browser behavior (comparison)

• With mhrv-rs proxy (passthrough_hosts active): Chrome shows ERR_CONNECTION_RESET
• Direct connection (no proxy at all, from same machine): ERR_CONNECTION_TIMED_OUT

This confirms that the firewall is actively resetting connections with the real SNI, while direct connections are dropped more silently (timeout).

Why this matters

These sites (deno.com, val.town, fly.io) are blocked in Iran. A direct connection with the real SNI is immediately cut by the firewall. If mhrv-rs could apply SNI-rewrite (like direct mode) for passthrough_hosts, the connection would pass the firewall and the site would open, because the ISP sees SNI=www.google.com and allows it.

Config File

{
  "mode": "apps_script",
  "google_ip": "216.239.38.120",
  "front_domain": "www.google.com",
  "script_id": "***",
  "auth_key": "***",
  "listen_host": "127.0.0.1",
  "listen_port": 8085,
  "socks5_port": 8086,
  "log_level": "info",
  "verify_ssl": true,
  "sni_hosts": [
    "www.google.com",
    "mail.google.com",
    "drive.google.com",
    "docs.google.com",
    "calendar.google.com",
    "accounts.google.com",
    "scholar.google.com",
    "maps.google.com",
    "chat.google.com",
    "translate.google.com",
    "play.google.com",
    "lens.google.com",
    "chromewebstore.google.com"
  ],
  "passthrough_hosts": [
  ".val.town",
  ".deno.com",
  ".fly.io"
  ],
  "fetch_ips_from_api": true,
  "max_ips_to_scan": 100,
  "scan_batch_size": 500,
  "google_ip_validation": true,
  "tunnel_doh": true,
  "block_doh": false
}

Log evidence

2026-05-05T17:40:38.040233Z  INFO dispatch deno.com:443 -> raw-tcp (direct) (passthrough_hosts match)
2026-05-05T17:40:42.007962Z  INFO stats: relay=86 (355KB) failures=18 coalesced=0 cache=0/0 (0% hit, 0KB) scripts=1/1 active
2026-05-05T17:40:46.440609Z  INFO dispatch deno.com:443 -> raw-tcp (direct) (passthrough_hosts match)
2026-05-05T17:40:48.046394Z  INFO dispatch deno.com:443 -> raw-tcp (direct) (passthrough_hosts match)
2026-05-05T17:40:54.625828Z  INFO dispatch clients4.google.com:443 -> sni-rewrite tunnel (Google edge direct)
2026-05-05T17:40:54.625842Z  INFO SNI-rewrite tunnel -> clients4.google.com:443 via 216.239.38.120 (outbound SNI=www.google.com)
2026-05-05T17:40:55.048821Z  INFO dispatch beacons.gcp.gvt2.com:443 -> sni-rewrite tunnel (Google edge direct)
2026-05-05T17:40:55.048836Z  INFO SNI-rewrite tunnel -> beacons.gcp.gvt2.com:443 via 216.239.38.120 (outbound SNI=www.google.com)
2026-05-05T17:40:56.444326Z  INFO dispatch deno.com:443 -> raw-tcp (direct) (passthrough_hosts match)
2026-05-05T17:41:03.776417Z  INFO dispatch deno.com:443 -> raw-tcp (direct) (passthrough_hosts match)
2026-05-05T17:41:13.077146Z  INFO dispatch clients4.google.com:443 -> sni-rewrite tunnel (Google edge direct)
2026-05-05T17:41:13.077162Z  INFO SNI-rewrite tunnel -> clients4.google.com:443 via 216.239.38.120 (outbound SNI=www.google.com)
2026-05-05T17:41:13.793771Z  INFO dispatch deno.com:443 -> raw-tcp (direct) (passthrough_hosts match)

@therealaleph

[Shjpr9]

This thing that you are trying to do is not what passthrough_hosts is for. You are trying to do something we call domain_fronting which you can find the documents here
passthrough_hosts is for the domains that are directly accessible on Iran's internet like github.com and deepseek.com.
Read those docs and if you don't understand anything, feel free to ask.

[Montazeran8]

This thing that you are trying to do is not what passthrough_hosts is for. You are trying to do something we call domain_fronting which you can find the documents here passthrough_hosts is for the domains that are directly accessible on Iran's internet like github.com and deepseek.com. Read those docs and if you don't understand anything, feel free to ask.

Thanks a lot for the detailed explanation and the pointer to fronting_groups — that really helped clarify the intended use of passthrough_hosts.

Just to give you the full picture of my situation: I'm completely unable to reach sites like val.town, deno.com, or fly.io directly, even for a fraction of a second. My ISP seems to block DNS resolution for these domains, any direct IP connection to CDN edges, and basically any traffic that isn't wrapped with SNI=www.google.com and routed through the Apps Script relay. So while fronting_groups is exactly what I'd need in theory, I can't pull the IP/SNI pairs because of the broken DNS.

My entire problem boils down to just the very first step: I need to sign up for an account on one of those platforms (using Google or GitHub OAuth) just once. The rest I can handle with mhrv-rs — I just need to get past that initial authentication flow, which I know is a known limitation of the Apps Script relay (as discussed in issue #723).

Do you think there's any chance someone could share a temporary or pre-deployed exit node URL for this one-time purpose? Or is there another way you'd suggest to get over this first hump, given the DNS and direct-connect restrictions?

Thanks again for your time and help.

[Montazeran8]

Final Update: Complete failure to sign up on val.town — root cause analysis and all attempts

I have exhausted every possible path to create an account on val.town through the proxy. Below is a systematic summary of what I tried and where each attempt broke.

1. Cookie loss hypothesis — disproven

I used curl through the proxy to check whether cookies were being dropped between requests. The test:

• First request to https://www.val.town (returned 200, no cookies set).
• Second request immediately to https://www.val.town/settings with the same cookie jar (also 200).

Even after repeating this multiple times to account for timeouts, the second request always succeeded. This proves the relay does preserve cookies. The session is not being lost.

2. Static asset blocking / CORS — confirmed as primary blocker

When loading val.town in a normal browser through the proxy, the Developer Console is flooded with:

Access to script at 'https://static2.esm.town/assets/index-C-dJ3-Rb.js' from origin 'https://www.val.town' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Every JS, CSS, and font file from static2.esm.town fails to load. The relay is stripping the Access-Control-Allow-Origin response header. The HTML skeleton loads, but none of the JavaScript that powers the signup buttons, OAuth flows, or dynamic forms runs. This explains why buttons appear dead and why the email verification input field is missing.

3. Bypassing CORS and timeouts with a special Chrome instance

I launched a Chrome window with all web security disabled, then used the ZeroOmega extension to route only val.town traffic through MHRV's SOCKS5 proxy while GitHub and other domains went directly (no proxy):

"C:\Program Files\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir="C:\chrome-temp"

With this setup, static assets loaded correctly and the signup buttons became functional.

4. GitHub OAuth signup — failed with internal val.town error

I clicked "Sign in with GitHub", was successfully redirected to GitHub, authorized the app, and the callback URL loaded without CORS or timeout errors:

https://www.val.town/api/auth/callback/github?code=...&state=...

However, val.town's frontend then crashed with:

Error: No result found for routeId "routes/api.auth.$"
    at pt (https://static2.esm.town/assets/chunk-OE4NN4TA-Cst8H5EW.js:5:9616)
    ...

This means the client‑side router did not recognize the callback route. The signup could not complete.

5. Email signup — failed with "Invalid code" despite correct code

The email verification page appeared. I received a valid code in my inbox, entered it correctly, but val.town responded with Invalid code. This suggests that the relay is losing the session state or verification token between the request that sends the code and the request that verifies it — a classic cookie/session mangling problem.

Conclusion

I have tried every possible workaround. The proxy breaks val.town's authentication at multiple independent levels:

• CORS headers are stripped → static assets fail to load → JavaScript never runs.
• Even when CORS is disabled, GitHub OAuth callback is not recognised by val.town's router.
• Email signup loses the verification session.

It is currently impossible to create an account on val.town through MasterHttpRelayVPN-RUST. I am completely stuck. Could someone provide a pre-deployed exit node URL, or point me to an alternative hosting platform that actually works?

@therealaleph

[therealaleph]

@(author) — accurate description of the gap. passthrough_hosts IS plain TCP (no MITM, no SNI rewrite) — the ISP sees the real SNI of the destination on the wire. If the destination is ISP-blocked, passthrough_hosts gives you no DPI cover.

The naming is the problem: "passthrough" reads like "pass through any DPI cover that's still active", but it actually means "pass through and bypass mhrv-rs's rewriting entirely." Documented but yes, surprising.

What you actually want for deno.com / val.town / fly.io: add them to a fronting group in fronting_groups, not passthrough_hosts. Fronting groups MITM at our local CA + re-encrypt upstream against a chosen edge IP with a chosen SNI — preserving the DPI cover.

For Fastly-fronted sites (Deno Deploy is on Fastly):

"fronting_groups": [
  {
    "name": "deno-fastly",
    "ip": "151.101.1.140",
    "sni": "www.python.org",
    "domains": ["deno.com", "deno.land", "deno.dev"]
  }
]

deno.com SNI on the wire becomes www.python.org (or whichever name your sni field picks); Iran ISP DPI sees a Python connection; Fastly's edge serves Deno. Same trick as our default google_ip + front_domain: www.google.com, just for a different edge.

fly.io and val.town (when it was supported) live on different edges (fly.io has its own ANYCAST IP space; val.town was on val.run's CDN). They don't fit the Fastly pattern. For those you'd need to know their edge IP + a co-tenant on the same edge with a non-blocked SNI to use as the front.

Roadmap: a "fronting_passthrough" mode that does the same thing as passthrough_hosts but with mandatory SNI rewrite to a user-specified safe SNI (without MITM). Logged for v1.9.x batch.

For now, add Deno-family domains to a Fastly fronting group, not passthrough_hosts. می‌بندم چون current architecture + workaround موجود است.

---

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

[Shjpr9]

I can't pull the IP/SNI pairs because of the broken DNS.

@Montazeran8
I've written a small script for myself that uses a list of dns to resolve a given domain and then uses an internal website to lookup its ip and get its ASN. I can share if you want

Enter the domain: deno.com
Resolver: 217.218.155.155 | 65.97ms
Answer(s):
69.67.170.170
--------------
Getting ip info....
Query IP:  69.67.170.170
Country:  Canada
ASN Name:  AMAZON-02
Saving the result...
Added/Updated deno.com in domain_ips.json
Press Enter to exit.