Skip to main content
← All guides

Fix Next.js “Blocked cross-origin request to Next.js dev resource”

Checked against the qURL™ CLI 3.4.1 source and documentation on October 9, 2026. Link and session behaviour is tested separately.

Content updated October 18, 2026. The verification date above records the original review; later behaviour checks are dated in the guide.

Why does next dev block requests when I open my app through a tunnel?

Since Next.js 16.2, next dev blocks requests to its dev-only resources from origins it does not know, so hot reload fails when you open the app through a tunnel. Add the tunnel’s hostname pattern to allowedDevOrigins in next.config.js, such as *.qurl.site or *.ngrok-free.app, and restart next dev. Production builds are not affected.

What you need

  • A Next.js app running with next dev, opened through a tunnel or another hostname
  • Your next.config.js (or next.config.ts)

Steps

  1. Read the origin from the log

    next dev logs “Blocked cross-origin request to Next.js dev resource … from “host”” and answers 403. The exact wording varies by release. Next.js 16.1 and earlier only warned: “Cross origin request detected from … to /_next/* resource.”

  2. Add the tunnel’s hostname to allowedDevOrigins

    Next.js matches only the hostname of the request’s Origin, so write entries without https:// and without a port. A * stands for exactly one label and ** for one or more, only at the start of a pattern. If you use Server Actions, add the same pattern to serverActions.allowedOrigins.

    // next.config.js
    module.exports = {
      allowedDevOrigins: ['*.qurl.site'], // or '*.ngrok-free.app', '*.trycloudflare.com'
      experimental: {
        serverActions: { allowedOrigins: ['*.qurl.site'] },
      },
    }
  3. Restart next dev

    Next.js reads allowedDevOrigins at start-up. next dev listens on every interface by default, so start it with -H 127.0.0.1 to keep it off your network while a tunnel or qURL reaches it on localhost.

    next dev -H 127.0.0.1

What the recipient sees

With the origin allowed, the page and its dev resources load through the link, and the hot reload socket can connect.

Which tool fits sharing a next dev server?

OptionChoose it whenTrade-off
qURLqURL fits when you want particular people to open the app running on your machine, with no account and no public URL.With qURL your computer and the app must stay running, and each person needs a link or an invitation from you.
ngrokngrok fits when you need a stable public URL, for example for webhooks, or want ngrok’s OAuth or IP rules in front of the app.ngrok needs an account and authtoken first, the URL is public, and free-plan browser visitors see a warning page.
Cloudflare Quick TunnelsA Cloudflare Quick Tunnel fits when you want a throwaway URL with no account, optionally behind an email PIN with --allowed-mail.A Cloudflare Quick Tunnel is public unless you set --allowed-mail, gets a new hostname each run, and does not support Server-Sent Events.
Tailscale FunnelTailscale Funnel fits when the machine is already on a tailnet and you want a stable public HTTPS name for it.Tailscale Funnel needs a tailnet, makes the app public on a ts.net hostname, and puts no access control on Funnel traffic.

Troubleshooting

If you seeDo this
Server Actions fail with “Invalid Server Actions request”The browser’s origin differs from the host your app receives. Add the tunnel’s pattern to experimental.serverActions.allowedOrigins too; for qURL that is *.qurl.site.
The pattern doesn’t matchDrop the scheme and port, and remember *.example.com does not match example.com itself. Partial wildcards inside a label are not supported.

Frequently Asked Questions

Why did this start in Next.js 16.2?

Earlier releases warned about cross-origin dev requests and allowed them. Next.js 16.2 enforces the dev-origin guard by default, so a tunnel’s hostname must now be listed in allowedDevOrigins.

Does this fix work on Next.js 16.4?

Yes. On October 18, 2026 we opened next dev 16.4.2 through a qURL link. With no config, next dev logged “Blocked cross-origin request to Next.js dev resource /_next/hmr” and edits never reached the browser opening the qURL link. allowedDevOrigins: ["*.qurl.site"] fixed hot reload. A Server Action still failed with “Invalid Server Actions request”, because the browser’s origin (r_….qurl.site) differs from the host the app receives (c-….qurl.site), until serverActions.allowedOrigins had *.qurl.site too.

Does allowedDevOrigins affect production?

No. It applies to dev-only assets and endpoints served by next dev. A production build served with next start is not affected.

Which pattern do I add for qURL?

*.qurl.site in allowedDevOrigins, and in serverActions.allowedOrigins if you use Server Actions. A qURL link opens the app on a qurl.site subdomain.

Who else can reach my app while the link is open?

Opening the link admits the network address it was opened from for the session, which lasts 1 hour by default. Other devices that share that public IP address, such as people on the same office or café network or VPN, can reach the app until the session ends. By default a link admits whoever opens it; access rules set through the API, such as IP allow and deny lists, can restrict that. Keep your app’s own sign-in for anything sensitive.

Publish your app now

Install the CLI, then run one command. No sign-up, no API key.

Install the CLI ↗

Contact sales

Contact our team for enterprise deployments.

Enterprise starts with a scoped, paid pilot on one application, typically 60 to 90 days, credited in full toward year one if you convert within 60 days. Then an annual package sized to what you protect. Not per seat.