App Proxy redirects to storefront path instead of proxying (302 → 404) — Dev Dashboard app

Dev Platform
1

Our app proxy never reaches our backend. Visiting https://sterapro.be/apps/mijn as a logged-in customer, Shopify responds with a redirect to https://sterapro.be/api/sso/token?shop=...&logged_in_customer_id=...&path_prefix=%2Fapps%2Fmijn&timestamp=...&signature=... — the storefront domain + our proxy URL’s path, including all signed proxy params — which 404s on the storefront. Our backend is never hit (nothing in our logs).

Replaying that exact signed request directly against our proxy URL returns a valid 200 JSON response, so our server and HMAC verification work correctly.

  • Org ID: 221195034
  • App ID: 379484733441
  • Shop: 0ancs7-zs.myshopify.com (sterapro.be)
  • Proxy config: prefix apps, subpath mijn, proxy URL https://app.sterapro.be/api/sso/token

App created in the new Dev Dashboard. We already tried: removing and re-adding the proxy with new releases (versions proxy-remove / proxy-readd, June 9), and a fresh reinstall on the store (June 10) — no change. Example failing request timestamp: 1781181919 (June 11, ±12:05 UTC).

Symptom matches threads 22359 and 22906.

2

Hey @Olivier_Terrie the first thing I would check is the shop-level App proxy setting in Admin:

Settings > Apps and sales channels > [your app] > App proxy

The reason I’d check there first is that the App proxy path can have per-shop configuration/customization which has been the cause in similar issues.

If the Admin value is correct, could you share a fresh X-Request-ID from the failing 302/404 response headers?

3

Thanks for the pointer! I checked the shop-level App proxy setting in Admin
(Settings → Apps and sales channels → Stera Pro Portaal → App proxy URL).
It’s correct and shows the expected customer-facing URL:

– Stera Pro (prefix “apps”, subpath “mijn”, no per-shop customization)

The backend proxy target is set in the Dev Dashboard to:

https://app.sterapro.be/api/sso/token

Fresh failing request, captured just now (2026-06-13, ~08:27 UTC):

  • Final response: 404 on
    – Stera Pro…
  • X-Request-ID: 55991209-7e03-4559-9ca6-cfac2019bc6e-1781339231

Note: that X-Request-ID is from the final 404 hop on the storefront. The preceding
302 from /apps/mijn is a same-origin redirect whose headers aren’t script-readable,
but both hops are on the same Shopify edge.

Extra datapoint: the redirect-instead-of-proxy behaviour reproduces even when NOT
logged in as a customer (logged_in_customer_id is empty), so it isn’t dependent on a
customer session. Our backend still never receives the request (nothing in our logs),
and replaying the signed URL directly against our proxy target still returns a valid
200 JSON.

4

Hey @Olivier_Terrie, thanks for sharing those details. I am going to locate the request in our logs.

Can you also clarify, if you are you currently running shopify app dev against this store, or have you at any point? If so, can you try running shopify app dev clean or cleaning the dev preview from the Dev Console in admin to make sure there’s no stale dev preview overriding your deployed config?

6

Hey @Olivier_Terrie, I was able to trace the logs based on the request id. From what I see, your proxy config is correct and the request is being forwarded to your backend as expected.

The one detail to be aware of is that the proxy always appends a trailing slash when forwarding, so your server receives a request to /api/sso/token/ instead of /api/sso/token.

What seems to be happening is your server is redirecting that trailing-slash path back to the version without it, but because that redirect goes through the proxy, it resolves against the storefront domain instead of your app, causing the 404.

To confirm (and resolve) this, make sure your server is configured to serve /api/sso/token/ directly instead of redirecting it. Once the trailing-slash form returns a 200, the proxy will relay that response to the browser and everything should work as expected.

7

Update: resolved — thanks @KyleG-Shopify, your trailing-slash diagnosis was spot on.

Root cause was on our side: our backend (Next.js on Vercel) issues a default 308
redirect from /api/sso/token/ (the trailing-slash form the proxy forwards) to
/api/sso/token. The browser resolves that redirect’s Location against the storefront
domain, which is what produced the sterapro.be/api/sso/token 404.

Fix: set skipTrailingSlashRedirect: true in next.config.ts so the route serves the
trailing-slash path directly with a 200 instead of redirecting. The proxy now relays
our JSON response and /apps/ works as expected.

One follow-up gotcha for anyone normalizing the trailing slash via a Next.js middleware
rewrite: NextRequest.nextUrl.clone() drops empty query params (e.g. logged_in_customer_id=),
which then breaks App Proxy HMAC verification. Preserve the raw query string instead.

Thanks again for tracing the logs!