Since Gradio 6.4 -> 6.8.0 Custom Domain doesnt work

[dtometzki]

Hi everyone,

since upgrading to Gradio 6.4 and higher, access via our custom domain no longer works.

Is there any specific configuration in Gradio (or during launch()) that needs to be enabled or adjusted to support custom domains again?

Thanks in advance.

[John6666]

The cause appears to be a major change on the Gradio side (see below).
If possible, I think it would be better to resolve this on the Hugging Face server side… [email protected]

---

What likely changed between Gradio 6.3 → 6.4+ (why “custom domain” suddenly breaks)

From 6.4 onward, Gradio’s frontend + URL/base-path plumbing is in a “sensitive” zone:

• SSR (server-side rendering) was re-enabled in the 6.4 timeframe. (Gradio)
• Gradio also bumped SvelteKit (the frontend framework Gradio uses) “for security reasons,” which tends to change how the browser computes/uses the app’s base URL, asset URLs, and navigation behavior. (Gradio)
• Immediately after, there were follow-up fixes specifically mentioning Spaces/private Spaces and CSS root issues. That’s a strong hint the “public URL / root path / static assets” logic was actively changing in this period. (Gradio)

The key practical implication

Gradio constructs a “public URL” for your app and uses it to fetch static assets and wire up interactive endpoints. If your reverse proxy / ingress / platform headers don’t correctly tell Gradio what the “outside” URL is, the app can load in a broken state. Gradio’s own nginx guide calls this out explicitly: it relies on X-Forwarded-Host, X-Forwarded-Proto, and root_path to build the public URL used for static assets. (Gradio)

So in many deployments, 6.4+ didn’t “break custom domains” by itself — it stopped accidentally working when the forwarded headers / base path were slightly wrong.

---

Recommended “fix order” (fastest to confirm → most invasive)

1) Confirm what kind of break you have (assets vs websockets vs proxy)

Open DevTools → Network and check:

• Are requests for …/assets/*.css or …/assets/*.js going to the wrong host, wrong scheme (http vs https), or missing a path prefix?
• Do you see websocket failures / queue calls hanging (often manifests as UI loads but interactions fail)?

This matters because the fixes differ.

Example of a very similar symptom: some Gradio assets/media being requested over http://… even though the site is https://…, causing mixed content and 404s behind a proxy. (GitHub)

---

2) Fix the reverse-proxy headers first (most common root cause)

If you’re behind nginx / ingress / load balancer, ensure you pass:

• Host
• X-Forwarded-Host
• X-Forwarded-Proto (must reflect the external scheme: https if TLS terminates upstream)

Gradio’s nginx guide is explicit that missing X-Forwarded-Host / X-Forwarded-Proto can leave the app “in a broken state.” (Gradio)

A typical nginx location block pattern (you may already have most of this) is also shown in real-world issues where CSS fails behind a reverse proxy; note the forwarding headers and websocket upgrade bits. (GitHub)

Why this is #1 in the order: it fixes both asset URL generation and interactive endpoints without changing your app code.

---

3) Explicitly set root_path (especially if you have a path prefix)

If your custom domain serves Gradio under a subpath (e.g. https://example.com/myapp), then root_path must match that mount point.

• Official docs: root_path is “often used behind a reverse proxy,” and should be "/myapp" in that case. (Gradio)
• The nginx guide also says you must set root_path for any subpath hosting. (Gradio)

In code:

demo.launch(root_path="/myapp")

Or via env var:

export GRADIO_ROOT_PATH="/myapp"

(Gradio)

Important workaround: Gradio allows root_path to be a full URL (https://…) if you want to override base URL computation entirely. (Gradio)
This is especially useful when you can’t fully control what headers reach the container/app.

---

4) If you see “https site but http assets” → fix X-Forwarded-Proto and forwarded trust

If the browser shows mixed content or requests some files over http://…, your proxy chain is almost always telling the app the scheme is http.

A concrete example: a user behind Kubernetes + proxy terminates TLS, but some Gradio asset/media requests still go to http://…, causing mixed content blocks. (GitHub)

Fix is typically:

• Ensure the outermost proxy sets X-Forwarded-Proto: https
• Ensure any inner proxy does not overwrite it incorrectly
• Optionally, set Forwarded: proto=https consistently (some stacks prefer the RFC header)

---

5) If UI loads but interactions fail only on the custom domain

This often means the interactive channel (queue/websocket/SSE endpoints) is broken under the custom domain but not under the raw host:port.

There’s a direct “custom domain works until you click/trigger something” precedent: a report where the app worked via https://<ip>:7860 but hung on events via mydomain.com. (GitHub)
Again, this is usually mismatched public URL / host headers / proxy upgrade behavior.

Prioritize:

• Header forwarding (Step 2)
• Websocket upgrade headers (if you use queue / streaming)
• Root path correctness (Step 3)

---

6) If you see /proxy= URLs or {"detail":"This URL cannot be proxied."}

Then you’re hitting Gradio’s proxying logic (common with certain file/media flows or gr.load(..., src="spaces") patterns).

There are two important facts from upstream:

• There are real-world errors where Gradio returns exactly {"detail": "This URL cannot be proxied."}. (GitHub)
• Gradio added SSRF-hardening that only allows proxying to known Hugging Face Space hosts (checks for *.hf.space) and rejects others. The code change literally says it only adds proxy URLs that end with .hf.space and otherwise won’t proxy. (GitHub)

Why this matters for custom domains:
If your deployment path causes Gradio to treat your custom domain as the thing to be proxied (instead of the underlying .hf.space host), proxying will be blocked by design.

Workarounds (in order):

1. Ensure the proxied upstream remains the .hf.space hostname (don’t rewrite it to the custom domain for internal proxy fetches).
2. Avoid the proxy path entirely (serve files directly from the app origin when possible).
3. If you control the app behavior, avoid features that force proxying (the exact trigger depends on your app; gr.load(..., src="spaces") is a known proxy user). (GitHub)

---

“There isn’t a magic launch() flag for custom domains”

What you typically need is one of these:

• Correct forwarded headers (X-Forwarded-Host, X-Forwarded-Proto) (Gradio)
• Correct root_path (subpath deployments) or full-URL root_path (override base URL computation) (Gradio)
• If proxy endpoints are involved, ensure you’re not tripping proxy allowlisting that rejects non-.hf.space hosts (GitHub)

---

Similar cases/issues you can compare against (useful for pattern-matching)

• Custom domain → interactions hang / “Event not found” (works on raw host:port, fails on domain) (GitHub)
• Some static/media requests go to http on an https site behind Kubernetes/proxy (mixed content / 404) (GitHub)
• Reverse proxy / port mapping causes CSS not to load (illustrates header patterns people use) (GitHub)
• root_path + CSS preload/base URL problems (shows how subtle base URL issues can be) (GitHub)
• {"detail":"This URL cannot be proxied."} (proxy restrictions in action) (GitHub)

---

High-quality docs/guides to apply directly

• Gradio’s official nginx reverse-proxy guide (headers + root_path guidance) (Gradio)
• root_path parameter docs (Interface/Blocks) (Gradio)
• mount_gradio_app docs (same root_path concepts, including full-URL override) (Gradio)
• Environment variable GRADIO_ROOT_PATH (Gradio)

---

If you want the most “surgical” next step

Apply Step 2 (forwarded headers) + Step 3 (root_path), then re-check the Network tab:

• If asset URLs are now correct and interactions work → you’re done.
• If you still see …/proxy=… or "cannot be proxied" → jump straight to Step 6 (proxy allowlisting angle).

[NJX-njx]

This is a known regression in Gradio 6.4+.

Workarounds:

1. Downgrade to Gradio 6.3.x temporarily
2. Check if your custom domain DNS is properly configured
3. Try using the Gradio hosting directly without custom domain

The team is aware of this issue - might be worth checking Gradio GitHub issues for a fix timeline.

[dtometzki]

Hello everyone,

Many thanks for the detailed information. I’ve switched back to Gradio 6.3.0 . I hope that a fix will be available in the near future.

Damian