Get past the ngrok browser warning (ERR_NGROK_6024)
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.
How do I get rid of the ngrok “You are about to visit” warning page?
ngrok shows the ERR_NGROK_6024 warning to browser traffic on the free plan. Requests you control can skip it with an ngrok-skip-browser-warning header or a non-standard User-Agent. A person clicking your link sees it once per domain every 7 days unless you upgrade to a paid plan. API and programmatic traffic never sees it.
What you need
- An ngrok endpoint on the free plan
- Or: the qURL CLI, if you want no warning page at all
Steps
For your own front end calling the ngrok URL, send the header
ngrok skips the page for a request that carries an ngrok-skip-browser-warning header with any value. A cross-origin fetch with a custom header triggers a CORS preflight, so the server must allow that header.
fetch('https://your-domain.ngrok-free.app/api/items', { headers: { 'ngrok-skip-browser-warning': 'true' }, })For scripts and tools, send a non-standard User-Agent
The page is shown only to browser traffic. curl, webhooks and API clients don’t see it, and any client can skip it by sending a User-Agent of its own, such as MyApp/0.0.1.
curl -H 'User-Agent: MyApp/0.0.1' https://your-domain.ngrok-free.app/For people you send the link to, upgrade or share without a warning page
A person clicking your link sends their browser’s own headers, so the header trick can’t help them: they see the page, click Visit, and a cookie hides it on that domain for 7 days. ngrok removes it on any paid plan. qURL shows recipients no warning page, and needs no account.
qurl publish http://127.0.0.1:3000 qurl share <CRID>
What the recipient sees
With qURL, the recipient clicks the link and lands on your app: no warning page, sign-up or install. With ngrok on the free plan, they see the warning once per domain every 7 days.
Which tool fits sharing an app with people who click a link?
| Option | Choose it when | Trade-off |
|---|---|---|
| qURL | qURL 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. |
| ngrok | ngrok 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 Tunnels | A 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 Funnel | Tailscale 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 see | Do this |
|---|---|
| The header is set but the warning still appears | The header has to be on the request the browser sends to ngrok. A header set by your server on its response does nothing. For a person clicking a link, there is no way to add it. |
| The fetch fails with a CORS error after adding the header | The custom header makes the browser send a preflight request. Allow ngrok-skip-browser-warning in your server’s Access-Control-Allow-Headers. |
| qurl publish says the local app is not accepting TCP connections | Start the app first and check that curl works on the same address. qurl publish connects to localhost as 127.0.0.1, so if your app listens only on IPv6 (on macOS or Linux, lsof -iTCP -sTCP:LISTEN -nP shows [::1]), publish 'http://[::1]:PORT' instead. Keep the quotes: zsh treats the brackets as a pattern. |
| The recipient sees “Access link invalid” | The link was already used or has expired. Run qurl share again and send the new link. |
| The recipient sees “Resource not found” | The resource was deleted after the link was made. Publish the app again, then run qurl share and send the new link. |
| publish rejects http://127.0.0.1 with “only HTTPS URLs are allowed”, or asks you to log in | You have a CLI older than 3.0. On macOS run brew update, then brew upgrade qurl; elsewhere install the latest release again. After updating, qurl --version should print 3.4.1 or later. |
| publish prints no Access: line, or the Access: line says public and you did not ask for public | With no Access: line, the CLI is older than 3.4.1: on macOS run brew update, then brew upgrade qurl; elsewhere install the latest release again. A resource that an older CLI published is public unless you published it with --private, and anyone who has the CRID of a public resource can open it. To make a public resource private, run qurl delete <CRID> and publish again with qurl 3.4.1 or later. The new resource is private and has a new CRID. |
| publish says this Linux session “can’t reach a systemd user manager” | You are in a container or sandbox without a user service manager. Run qurl publish with --foreground; sharing lasts as long as that process runs. |
| publish says “Quota Exceeded” with “protected resource limit reached”, or “Your qURL account has reached a plan limit” | You can see this without an account: a device with no account can keep up to 3 active resources, with links that last up to 24 hours. Run qurl list --status active, then qurl delete <CRID> for any you no longer need (it asks you to confirm; --yes skips that). qurl stop keeps the resource, so it does not free a slot. |
Frequently Asked Questions
Why does ngrok show this page?
ngrok says it displays the page to prevent abuse. The page tells visitors the site is served for free through ngrok and that they should visit only if they trust whoever sent the link.
Does the warning break webhooks?
No. ngrok shows it only in front of HTML browser traffic; it does not affect APIs or endpoints accessed programmatically, so webhook senders reach your app directly.
Which alternatives have no warning page?
qURL shows recipients none: the access link opens the app. Microsoft dev tunnels, zrok public shares from unverified free accounts, Pinggy and Serveo free tunnels, and localtunnel all show one. Cloudflare does not document one for quick tunnels.
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.