n8n setup problems: the deceptive-site flag and localhost webhook links, fixed at the source

Short answer

Two failures dominate the October 15–17 signal log, which counted 6 setup-breakage items in that three-day window only: a Google deceptive-site warning on a fresh self-hosted instance, and queue-mode waiting links that point to localhost. Most of this page is host-independent. Both fixes live in n8n and Google configuration. The table shows where your host changes the work: preinstall, domain, HTTPS, proxy, environment variables, workers, and onboarding. Checked October 18, 2026. A dash means not yet verified.

In October 2026, reports described a fresh self-hosted instance flagged on sign-in and usage-style admin URLs, and send-and-wait links written as http://localhost:5678/webhook-waiting/… while ordinary webhook URLs looked right. The reports are a pattern. They are not a cause, a frequency, or a host.

Preinstalled is the install. It is not a finished domain, certificate, proxy, or webhook URL unless that host's row quotes the page that says so. A dash in the table is — / not yet verified. It is not “none”, and it is not “the host does this”.

“Deceptive site ahead” on a fresh install — what is known, and what isn't

In October 2026, reports described a fresh self-hosted instance flagged on sign-in and usage-style admin URLs. The reports are a pattern. They are not a cause, a frequency, or a host. The October 15–17 signal log counted 6 setup-breakage items in that three-day window. This page does not turn that count into a rate. The warning name is the wording in those reports. This page does not assign a cause: not the subdomain, not the look of a login page, not the age or ending of the domain, and not the host or the install method.

Check the flagged URLs before you treat the warning as a mistake

Open the flagged URLs and look for unexpected redirects or injected content before you treat the warning as a false positive. That check is the first step on this page. It is a prudence step written here. It is not a sentence copied from Google's help, and it is not a finding that the instance is clean.

Google's review steps, as written on October 18, 2026

The steps below are from Google's Security issues report help, fetched and read Oct 18, 2026. The report itself opens at Search Console security issues.

• Google says Safe Browsing displays warnings based on the browsing context, so you may or may not be able to reproduce a warning. The same page says to rely on the Security Issues report as the source of truth for whether any security issues exist for the site, or whether they have been fixed.
• If the site has security issues, the report shows a count at the top. If it has none, the report shows a green check mark and a message to that effect.
• To fix an issue the report lists: expand the description, follow its learn-more link, use the sample of affected pages, and fix the issue throughout the site. Fixing some pages does not earn a partial return. If the report lists more than one issue, fix all of them.
• When every issue listed in the report is fixed on all pages, select Request Review in the Security Issues report. Google says a good request explains the exact quality issue, describes the steps taken to fix it, and documents the outcome. Progress arrives by email. Do not resubmit before a decision on an outstanding request.
• Google's wording on timing: “Most reconsideration reviews can take several days or weeks.” That sentence is about a reconsideration review. It is not a promise that this warning clears.

The same help page has a “Deceptive pages” section. Google defines those pages as content that tricks visitors, and it calls that social engineering. This page does not classify a fresh n8n sign-in as social engineering, and it does not classify the reported warning as a phishing listing. What that section tells a site owner to do, still on the page read Oct 18, 2026:

1. Visit the example pages and look for the deceptive content. Google mentions the URL Inspection tool for mobile and desktop views.
2. Fix any pages that engage in social engineering. If you believe Safe Browsing classified a web page in error, Google's sentence is “please report it here.” That link is Report a Page to Google Safe Browsing, which is the title of the form fetched the same day.
3. When you confirm the problem is fixed, request a security review in the Security Issues report. Google's wording in that section: “A review can take from a few days to a few weeks to complete.” That is the same kind of review timing. It is not a promise that this warning clears.

Google's Safe Browsing reporting page, last updated 2024-09-18 UTC and fetched Oct 18, 2026, says the same form is for URLs that are currently on the phishing list but shouldn't be. The Search Console deceptive-pages section links that form for a classification you believe is an error. This page quotes both sentences. It does not decide which list a fresh n8n URL is on.

No cause is established. No prevention is established. No host in this Oct 18, 2026 pass is documented to prevent or clear a Safe Browsing flag. That is what the official pages said, or did not say, on that date. It is not a claim that a flag is impossible, and it is not a claim about why a flag appears. The host table below has no Safe Browsing column.

Why queue-mode send-and-wait links point to localhost

The same October 2026 reports described send-and-wait links written as http://localhost:5678/webhook-waiting/… while ordinary webhook URLs looked right. The reports are a pattern. They are not a cause, a frequency, or a host.

How n8n builds the URL

From Configure webhook URLs with reverse proxy, checked Oct 18, 2026: n8n creates the webhook URL by combining N8N_PROTOCOL, N8N_HOST, and N8N_PORT. Behind a reverse proxy that combination will not work, because n8n runs internally on port 5678 and the proxy exposes it on port 443. Set N8N_WEBHOOK_URL so n8n can display the URL in the editor and register the correct webhook URLs with external services. That variable replaces WEBHOOK_URL, which is deprecated from n8n 2.35.0. n8n logs a deprecation warning if you still use the old name. Set N8N_PROXY_HOPS to 1. On the last proxy in the request path, set X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto.

The endpoints page, same date, says N8N_WEBHOOK_URL sets the base URL for both test and production webhooks when n8n runs behind a reverse proxy. WEBHOOK_URL is a deprecated alias from 2.35.0. It still works, and n8n logs a deprecation warning on startup. The waiting-webhook path on that page is webhook-waiting.

What queue mode adds

From Enable queue mode, checked Oct 18, 2026: when n8n runs with queues, production workflow executions are processed by worker processes. For webhooks, the HTTP request is received by the main or webhook process, and the workflow execution is passed to a worker. Redis is the message broker, and the database persists data, so access to both is required. Running a distributed system with this setup over SQLite isn't supported. Running n8n with execution mode set to queue with an SQLite database isn't recommended. The same page points at n8n's supported PostgreSQL versions for the database. Set EXECUTIONS_MODE to queue on the main instance and on any workers.

A load balancer is in that page only when you run multiple webhook processes. Paths it names: /webhook/* for webhook triggers, and /webhook-waiting/* for human-in-the-loop endpoints used by nodes that perform send-and-wait. Those paths go to the webhook pool. Other paths go to the main process. Webhook processors rely on Redis and need EXECUTIONS_MODE set too. Whether you need workers at all is a sizing question on how much RAM and CPU n8n needs.

Where to set the webhook URL, and the worker question

The queue-mode page says to configure the webhook URL by running the command on the machine running the main n8n instance. N8N_WEBHOOK_URL is available from n8n 2.30.0. On earlier versions, that page says to use WEBHOOK_URL. The queue-mode environment variables page, read the same day, does not list N8N_WEBHOOK_URL. No n8n page read on Oct 18, 2026 says that workers build the waiting link, that every worker must have the variable, or that an execution already waiting keeps the old URL. The docs instruction is to set the variable on the main instance. The reported pattern is waiting links that still show localhost while ordinary webhook URLs look right. If links still point to localhost, check that the variable is set everywhere your setup runs n8n processes. That last sentence is a diagnostic question. It is not an official worker rule.

Diagnostic checklist

1. Is N8N_WEBHOOK_URL set to the public base URL, the one the reverse-proxy page describes?
2. The queue-mode page names the machine running the main instance. If links still point to localhost, check that the variable is set everywhere your setup runs n8n processes. That check is a question, not a documented worker requirement.
3. Open a new send-and-wait after the change and read the link in the browser. That re-test is a check. It is not a documented rule that an execution already waiting changes its URL.

The setup surface your host does, or doesn't, do for you

Most of both fixes are host-independent. They live in the n8n and Google configuration above. A host changes the work only on the surfaces in this table: what is preinstalled, who points the domain, who handles HTTPS, whether a reverse proxy is documented, where environment variables are set (including on workers, when a page says so), whether queue mode is provisioned, and what onboarding the host actually describes. “One-click”, “managed”, and “PaaS” are dataset labels. They do not fill a cell.

Order is dataset order. Affiliate status is not an input. This table is not a ranking. n8n Cloud is the row whose pages say n8n runs the instance and no installation is required. That contrast is Cloud only, and only as far as the Cloud pages quoted in that row. A blank Cloud cell stays blank. If the setup work is the cost you are weighing, n8n Cloud vs self-hosted prices that choice, and the renewal-aware calculator is on that page. Managed onboarding is part of what a managed price buys only where a row quotes that scope. The dated tables are on what n8n costs at 2,500, 10,000, and 50,000 executions a month.

No host in this Oct 18, 2026 pass is documented to prevent or clear a Safe Browsing flag. That is what the official pages said, or did not say, on that date. It is not a claim that a flag is impossible, and it is not a claim about why a flag appears. This table has no Safe Browsing column. This site has not installed n8n on any of these hosts.

Disclosure: Some host links below are affiliate links. We may earn a commission if you sign up, at no extra cost to you. Prices and order are not affected.

Plan names are the plans in prices.json. Dated prices: n8n hosting prices — October 2026. This page did not re-check those prices. How checks work. Price changelog. For fit and price, see best n8n hosting, cheapest way to host n8n, and free n8n hosting.

One-click vs bare VPS vs managed and PaaS — what “preinstalled” leaves for you

Read the three labels against the same columns. This section applies the table. It does not add a host claim that the table does not already quote. A side-by-side of a one-click n8n VPS and a bare VPS is on Hostinger vs Contabo. This page does not repeat that comparison. Every plan by install type is on One-click n8n hosting vs bare VPS.

One-click

The dataset's one-click plans are Hostinger KVM and OVHcloud. Preinstalled is what those pages say is already on the image. OVHcloud's product page, quoted in the row, says you are responsible for securing the operating system and the n8n application, including enabling HTTPS and keeping n8n updated. Domain, certificate, and environment variables stay in that row, including the parts the install guide still assigns to you. Hostinger's KVM row is the template article and the domain article, including the A record and the WEBHOOK_URL name that article still uses.

Bare VPS

On a bare VPS, every surface is yours unless that row found an official sentence that says otherwise. Contabo's stored plan is a bare VPS. The help article also documents an optional 1-click add-on, and the row keeps those two facts apart. DigitalOcean's tracked plans are Droplets. The Marketplace 1-Click is a different image, so its DNS steps stay out of the Droplet cells. Hetzner, Linode, and netcup have no n8n setup page in this pass, so those cells stay —. Vultr's row is the deploy guide you run, including Traefik, not a claim that the plan arrives with n8n already configured.

Managed and PaaS

Managed and PaaS labels prove nothing until the row quotes a scope. Hostinger Managed n8n, Elestio, Render, Railway, and Sliplane each have their own sentences in the table, including the cells left as —. n8n Cloud stays the contrast case from the section above: n8n runs the instance, and only the Cloud pages say how far that goes. Several host guides still name WEBHOOK_URL. n8n's endpoints page says that name is deprecated from 2.35.0. The table quotes the host page as it was fetched, and it quotes the deprecation beside it.

Once the public URL is in place, keeping the instance updated is the next job. How to update n8n safely — and who patches it on your host is that page: set up right, then keep it patched. This page does not re-teach the update sequence.

A first-hour setup checklist

These steps do not depend on which host you picked. Before you change a proxy, an environment variable, or queue mode on an instance that already has workflows, take a full backup. What a complete n8n backup includes is the list, including the encryption key.

• A real domain and HTTPS, in place before you share links. The host table quotes a host doing that only where its own page says so.
• N8N_WEBHOOK_URL set to the public base URL, so n8n displays and registers webhook URLs on that URL. n8n's reverse-proxy page says to set it when n8n listens on 5678 and the proxy exposes 443.
• Behind one proxy: N8N_PROXY_HOPS=1, and X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto on the last proxy. That is the reverse-proxy page.
• One test webhook and one send-and-wait, both opened in the browser, after the variable is set.
• Queue mode only after that check. EXECUTIONS_MODE=queue on the main instance and on workers. Redis is the broker. A distributed queue setup over SQLite is not supported, and queue mode on SQLite is not recommended. The queue-mode page points at supported PostgreSQL versions for the database. Then open a new waiting link. That re-test is a check.

Domain and HTTPS are quoted from a host only in the table above. The webhook URL, proxy hops, and forwarded headers are the reverse-proxy page and the endpoints page. Queue mode, Redis, SQLite, and the PostgreSQL versions link are the queue-mode page. Opening a new waiting link after the change is a check, as in the diagnostic list above. All of those pages were read Oct 18, 2026.

FAQ

Am I hacked if Chrome flags my new n8n?

That is not established. A deceptive-site warning on a fresh instance is a reported pattern from the October 15–17 signal log, not a diagnosis. Before treating it as a false positive, check the flagged URLs for unexpected redirects or injected content. Then use Google's Security Issues report in Search Console, which Google says is the source of truth for whether a security issue exists when you cannot reproduce the warning. If the report lists an issue, Google's page says to fix it across the site and select Request Review. If you believe Safe Browsing classified a page in error, Google's deceptive-pages section links to the Safe Browsing report form. No cause is established, no host is documented to prevent or clear the flag, and Google's “several days or weeks” line is about a reconsideration review, not a promise that this warning clears. Checked Oct 18, 2026.

Why do only my send-and-wait links point to localhost, not my webhooks?

n8n builds the webhook URL from N8N_PROTOCOL, N8N_HOST, and N8N_PORT. Behind a reverse proxy that combination is wrong, because n8n listens on 5678 and the proxy exposes 443, so you set N8N_WEBHOOK_URL. The queue-mode page tells you to run that command on the machine running the main instance. It also says /webhook-waiting/* is the human-in-the-loop path for send-and-wait, routed to the webhook pool when you run multiple webhook processes. The queue-mode environment-variable page does not list N8N_WEBHOOK_URL, and no n8n page read on Oct 18, 2026 says workers build the waiting link or must have the variable. If links still point to localhost, check that the variable is set everywhere your setup runs n8n processes. That is a diagnostic check, not an official worker rule.

Should I set N8N_WEBHOOK_URL or WEBHOOK_URL?

Set N8N_WEBHOOK_URL. The endpoints page says it is the base URL for both test and production webhooks behind a reverse proxy. WEBHOOK_URL is a deprecated alias from n8n 2.35.0. It still works, and n8n logs a deprecation warning. The queue-mode page says N8N_WEBHOOK_URL is available from n8n 2.30.0 and earlier versions use WEBHOOK_URL. Host guides fetched on Oct 18, 2026 for Hostinger's VPS domain change, Render, Railway, and OVHcloud's Compose example still name WEBHOOK_URL. Those sentences are quoted in the table as what the host page says. They are not the current n8n name.

Does a one-click install include domain and HTTPS setup?

Only where that host's page says so. One-click is the install, not the rest of the surface. Hostinger's KVM template opens on an https hostname Hostinger provides, and a separate article has you add an A record for your own domain. OVHcloud's pre-installed image still has you set the domain and a Let's Encrypt email in .env. Contabo's optional 1-click script includes Let's Encrypt and Caddy, and the dataset plan itself is a bare VPS unless you order that add-on. Every other domain or HTTPS cell is in the table, with a dash where the official page did not say. A dash means not yet verified. Checked Oct 18, 2026.

Can my host fix a Safe Browsing flag for me?

No host in this October 18, 2026 pass is documented to prevent or clear a Safe Browsing flag. That is what the official pages said, or did not say, on that date. It is not a claim that a flag is impossible, and it is not a claim about why a flag appears. The host table has no Safe Browsing column.

Do I need queue mode at all?

Queue mode is the scaling layout: one main instance and workers, with production executions on the workers. Set EXECUTIONS_MODE=queue on the main instance and the workers. Redis is the broker, and the database has to be reachable. A distributed setup over SQLite is not supported, and queue mode on SQLite is not recommended. The queue-mode page points at supported PostgreSQL versions. Whether you need that layout is a sizing question, covered on the RAM and CPU guide at /n8n-vps-requirements/. Checked Oct 18, 2026.