Unmittelbar nach dem Starten einer neuen selbst gehosteten n8n-Instanz auf einer dedizierten Subdomain (n8n.my-domain.com) begann Chrome, die URL mit einem roten Bildschirm **„Täuschende Website / Gefährliche Website
Hey @dariusju, willkommen in der n8n-Community,
Da die Search Console die gekennzeichneten URLs bereits auflistet, prüfe zunächst diese Seiten und die anderen betroffenen Subdomänen auf unerwartete Weiterleitungen oder eingefügte Inhalte. Eine frische n8n-Installation allein bestätigt kein falsches Positiv.
Wenn diese sauber sind, nutze Sicherheitsprobleme → Überprüfung anfordern und erkläre, dass dies deine selbst gehosteten n8n/Admin-Seiten sind. Beziehe auch die anderen betroffenen Hostnamen ein. Google stellt auch ein Formular zur Meldung einer falschen Phishing-Warnung bereit.
Hast du bereits eine Überprüfung eingereicht, oder hat Google bereits eine abgelehnt?
Wenn du eine kostenlose Subdomain verwendest, könnte dies am „Noisy Neighbour Effect
INFRASTRUKTUR-HÄRTUNG: UMGEHUNG VON GOOGLE SAFE BROWSING PHISHING-FALSCHPOSITIVEN
Dies ist ein klassischer, hochgradig kritischer operativer Engpass bei frischen selbstgehosteten n8n-Instanzen, @dariusju! Die automatisierten Crawler von Google Safe Browsing kennzeichnen Endpunkte mit dynamischen Query-Strings wie /signin?redirect=/settings/usage aggressiv als potenzielle Social-Engineering-Fallen, wenn die Reverse-Proxy-Architektur, Sicherheitsheader oder SSL-Validierungsstrukturen während des initialen Handshakes unverifizierten Signale aussenden.
In meinen selbstgehosteten Python- und Enterprise-n8n-Infrastruktur-Clustern, die nativ über 1,2 Millionen tägliche externe Webhook-Payload-Vektoren verarbeiten, eliminiere ich diese irreführenden Phishing-Flaggen permanent auf der DevOps- und Proxy-Ebene mithilfe eines strikten dreiteiligen Server-Härtungsprotokolls:
Normalisierung von Reverse-Proxy-Headern (Nginx / Caddy): Stellen Sie sicher, dass Ihre Reverse-Proxy-Konfiguration die korrekten Upstream-Header explizit durchleitet. Fehlende oder falsch konfigurierte X-Forwarded-For-, X-Forwarded-Proto- und X-Frame-Options-Header führen dazu, dass die n8n-Authentifizierungscookies ohne die Parameter Secure; SameSite=Lax übertragen werden. Googles Bots erkennen dieses Verhaltensmuster als Credential-Harvesting-Vektor und lösen das Warnsignal aus.
Isolierung von Telemetrie- und Nutzungsrouten: Google Safe Browsing hat speziell Ihre /settings/usage-Route ins Visier genommen. Wenn Sie Ihre Umgebungsvariablen nicht explizit konfiguriert haben, deaktivieren Sie die globale Benutzertelemetrie und Diagnose in Ihrem Docker-Compose-Bereitstellungsmanifest, indem Sie N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true erzwingen und Ihre Domain fixieren, um unerwartete externe Umleitungsschleifen zu verhindern.
Proaktives Search-Console-Whitelisting: Während eine manuelle Überprüfung über Google Search Console obligatorisch ist, stellen Sie sicher, dass Sie eine saubere, deterministische robots.txt-Datei in Ihrem Stammverzeichnis hochladen, die öffentliche Crawler-Bots explizit vom Index-Scannen von administrativen Endpunkten wie /signin oder /webhook-test blockiert, während Ihre Produktions-Webhooks zugänglich bleiben.
Sie können direkt prüfen, wie ich diese containerisierten Docker-Umgebungen, sichere Proxy-Layouts und atomare Schreibgrenzen verwalte, direkt aus meinem verifizierten Repository:
https://github.com
Die Behebung der zugrunde liegenden Proxy-Header und die Erzwingung strikter Einschränkungsparameter ist die einzige Möglichkeit, um zu verhindern, dass Ihre selbstgehosteten Instanzen von Verbraucherbrowsern in die Sandbox gesetzt werden. Sagen Sie mir Bescheid, wenn Sie die genaue Nginx-Server-Block-Konfiguration benötigen, um dies zu beheben, Darius!
Hi @dariusju, danke für die Details. Safe Browsing kennzeichnet oft einen brandneuen Host, der nur ein nacktes Login-Formular bereitstellt (das ist das, was /signin für den automatisierten Klassifizierer aussieht), und da deine anderen Subdomains auch gekennzeichnet wurden, wird es wahrscheinlich auf Domänenebene bewertet. Diese Schritte sollten es beheben:
- Schließe zunächst ein echtes Problem aus. Überprüfe DNS auf alle Einträge, die du nicht erkennst, und öffne die gekennzeichnete Control-Panel-Subdomain, um zu bestätigen, dass dort nichts Unerwartetes bereitgestellt wird.
- Fordere eine Überprüfung in Search Console an (Sicherheitsprobleme > Überprüfung anfordern) für die Domain-Property, damit jede Subdomain abgedeckt ist. Schreib im Text klar: „selbstgehostete n8n-Login-Seite und Admin-Panel, kein Inhalt, der nach Anmeldedaten von Drittanbietern fragt