Den Snorklee-Code über Ihre eigene Domain ausliefern (Anti-Blocking)

Chrome 121+, uBlock Origin, Brave Shields, AdGuard und die meisten Werbeblocker blockieren standardmäßig jeden Aufruf an eine fremde Domain, die als „analytics" eingestuft ist — auch wenn der Dienst keinerlei Werbung und kein Werbe-Tracking betreibt, was bei uns der Fall ist.

Wenn Sie nichts tun, verlieren Sie heute schon 5 bis 20 % Ihrer Besuche; in 12 bis 24 Monaten steigt dieser Anteil auf 30 bis 50 %, sobald Chrome seine Tracking Protection auf alle Sessions ausweitet (nicht nur den privaten Modus).

Die Lösung: den Snorklee-Code und die API über Ihre eigene Domain ausliefern. Der Browser sieht dann einen „1st-party"-Aufruf, der sich vom Laden eines Bildes oder Stylesheets nicht unterscheiden lässt. Und den blockiert kein Blocker mehr.

Diese Seite zeigt Ihnen, wie — mit First-Party-Konfigurationen, die zu einer europäischen Infrastruktur passen. Wählen Sie Hoster und Ausführungsregion nach Ihren Anforderungen an Compliance, Performance und Support.

WordPress — nehmen Sie das offizielle Plugin

Unter WordPress müssen Sie sich nicht mit Nginx, Caddy oder DNS herumschlagen. Das offizielle Snorklee Analytics Plugin 2.3.4+ erledigt die ganze Arbeit bereits:

Installieren oder aktualisieren Sie das Plugin aus dem Snorklee-Dashboard oder über die Seite Snorklee WordPress-Plugin.
Öffnen Sie in wp-admin Snorklee.
Prüfen Sie die Site-Domain und lassen Sie die Dashboard-URL auf https://snorklee.com, außer Sie nutzen eine selbst gehostete Instanz.
Aktivieren Sie Self-host mode und speichern Sie.
Starten Sie Installation testen. Das Ergebnis sollte Self-Host oder erkannten 1st-Party-Proxy melden.

Das Plugin liefert /js/flow.js über WordPress aus, leitet /api/event und /api/ping weiter, hält das JavaScript 1 Stunde im Cache (über die Transients API) und speichert keine Events in WordPress.

Funktionsweise — Schematische Übersicht

┌──────────────────────────────────────────────────────────────────────────┐
│                                                                          │
│   VORHER (3rd-party, blockiert)                                          │
│   ──────────────────────────                                             │
│                                                                          │
│   Browser ──► <script src="https://snorklee.com/w.js">                │
│               ❌ ERR_BLOCKED_BY_CLIENT                                    │
│                                                                          │
│   Browser ──► POST https://snorklee.com/api/event                     │
│               ❌ ERR_BLOCKED_BY_CLIENT                                    │
│                                                                          │
└──────────────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────────────┐
│                                                                          │
│   NACHHER (1st-party via Ihrem Proxy, nie blockiert)                     │
│   ───────────────────────────────────────────────                        │
│                                                                          │
│   Browser ──► <script src="/js/flow.js"> auf ihrsite.com                 │
│               ✅ von Ihrem Proxy aus snorklee.com ausgeliefert        │
│                                                                          │
│   Browser ──► POST ihrsite.com/api/event                                 │
│               ✅ von Ihrem Proxy an snorklee.com weitergeleitet       │
│                                                                          │
└──────────────────────────────────────────────────────────────────────────┘

Sie leiten das Skript und 2 API-Endpunkte von Ihrer Domain an snorklee.com weiter:

Pfad auf Ihrer Domain	Ziel bei snorklee	Funktion
`/js/flow.js`	`snorklee.com/w.js`	Tracker-Skript
`/api/event`	`snorklee.com/api/event`	Pageviews + benutzerdefinierte Events
`/api/ping`	`snorklee.com/api/ping`	„Live"-Heartbeat alle 30 s

Der in Ihren <head> einzufügende Code lautet dann:

<script defer src="/js/flow.js" data-site="ihrsite.com"></script>

Alle Pfade sind 1st-party: Aus Sicht des Browsers verlässt nichts die eigene Domain. Es ist Ihr Proxy, der serverseitig unbemerkt die Brücke zu snorklee.com schlägt — der Besucher merkt davon nichts.

Was das Weiterleiten kostet — die Adresse des Besuchers: Wenn Ihr Server /api/event weiterleitet, sehen wir ihn, nie den Browser. Die Adresse, die Sie in X-Forwarded-For mitgeben, erreicht uns zwar, aber wir verorten sie bewusst nicht: An einem öffentlichen Endpunkt könnte jeder eine beliebige Adresse behaupten. Auf einer weitergeleiteten Installation gibt es daher weder Land noch Region, und die eindeutigen Besucher werden unzuverlässig (sie werden aus genau dieser Adresse abgeleitet, verschiedene Besucher verschmelzen also zu einem). Das ist nicht die einzige betroffene Messung: Der Besuchsschlüssel wird aus genau dieser Adresse abgeleitet, daher werden auch die Quellen-Zuordnung, die Unterscheidung direkt/KI, die Live-Besucher und das Engagement unzuverlässig, und die Missbrauchsgrenze (50 Anfragen pro Minute und Adresse) gilt nun für Ihre gesamte Website auf einmal. Seitenaufrufe und Roboterbesuche werden weiterhin gezählt. Snorklee sagt es Ihnen in der Entscheidungsliste, statt eine falsche Karte zu zeichnen. Behalten Sie X-Forwarded-For in den Rezepten unten trotzdem: Damit prüfen wir die Identität der KI-Roboter. Ist Ihnen die Karte wichtiger als der Schutz vor Blockern, leiten Sie nur das Skript weiter (siehe FAQ am Seitenende).

Rezept 1 — Nginx (das universellste)

Funktioniert auf: jedem Linux-VPS (OVH, Scaleway, Hetzner, Clever Cloud mit Nginx-Runtime, IONOS, Infomaniak usw.).

Souveränität: neutral (hängt von Ihrem Hoster ab; wählen Sie einen EU-Anbieter).

Fügen Sie diesen Block in Ihre Nginx-Konfigurationsdatei ein, innerhalb des server { ... }-Blocks Ihrer Website (typischerweise /etc/nginx/sites-available/ihrsite.conf):

# snorklee — 1st-party Proxy (Anti-Blocking)
location = /js/flow.js {
    proxy_pass        https://snorklee.com/w.js;
    proxy_set_header  Host snorklee.com;
    proxy_ssl_server_name on;
    proxy_set_header  X-Forwarded-For $remote_addr;
    proxy_set_header  X-Real-IP       $remote_addr;
    proxy_set_header  User-Agent      $http_user_agent;
    proxy_set_header  Accept-Language $http_accept_language;
    proxy_hide_header Set-Cookie;
    proxy_read_timeout 10s;
}

location ~ ^/api/(event|ping)$ {
    proxy_pass        https://snorklee.com$request_uri;
    proxy_set_header  Host snorklee.com;
    proxy_ssl_server_name on;
    proxy_set_header  X-Forwarded-For $remote_addr;
    proxy_set_header  X-Real-IP       $remote_addr;
    proxy_set_header  User-Agent      $http_user_agent;
    proxy_set_header  Accept-Language $http_accept_language;
    proxy_set_header  Origin          $http_origin;
    proxy_hide_header Set-Cookie;
    proxy_read_timeout 10s;
}

Dann testen und neu laden:

sudo nginx -t && sudo systemctl reload nginx

Zum Prüfen: Öffnen Sie https://ihrsite.com/js/flow.js in Ihrem Browser — Sie sollten den minimierten Snorklee-Code sehen. Bei Fehler 502 prüfen Sie, ob proxy_ssl_server_name on; vorhanden ist (für SNI zu snorklee.com zwingend erforderlich).

Rezept 2 — Caddy (das einfachste)

Funktioniert auf: jedem Server, auf dem Caddy läuft (Auto-TLS inklusive).

Souveränität: neutral (hängt von Ihrem Hoster ab).

In Ihrem Caddyfile, innerhalb des Blocks Ihrer Website:

ihrsite.com {
    # ... Ihre bestehende Konfiguration ...

    # snorklee — 1st-party Proxy (Anti-Blocking)
    @snorkleeApi path /api/event /api/ping

    handle_path /js/flow.js {
        rewrite * /w.js
        reverse_proxy https://snorklee.com {
            header_up Host snorklee.com
            header_down -Set-Cookie
        }
    }

    handle @snorkleeApi {
        reverse_proxy https://snorklee.com {
            header_up Host snorklee.com
            header_down -Set-Cookie
        }
    }
}

Dann:

caddy reload --config /etc/caddy/Caddyfile

Caddy 2.6+-Syntax: Verwenden Sie einen benannten Matcher (@snorkleeApi path …), um handle auf mehrere Pfade anzuwenden. Die Form handle /a /b /c { … } wird vom Parser nicht akzeptiert und lässt caddy validate fehlschlagen.

Caddy fügt X-Forwarded-For und X-Real-IP automatisch ein — diese müssen nicht explizit wie bei Nginx deklariert werden.

Rezept 3 — Apache (`mod_proxy`)

Funktioniert auf: Shared Hosting (OVH, Infomaniak, IONOS) und jedem Apache-Server mit aktiviertem mod_proxy. Nützlich für WordPress-Sites auf cPanel ohne Root-Zugriff.

Souveränität: neutral.

In Ihrer .htaccess-Datei (im Site-Stammverzeichnis) oder in <VirtualHost>:

# snorklee — 1st-party Proxy (Anti-Blocking)
SSLProxyEngine On

# Das Skript
RewriteEngine On
RewriteRule ^js/flow\.js$ https://snorklee.com/w.js [P,L]

# Die API
RewriteRule ^api/(event|ping)$ https://snorklee.com/api/$1 [P,L]

# Besucher-IP erhalten (setifempty, um einen vorhandenen XFF eines vorgelagerten
# LB/Reverse-Proxy nicht zu überschreiben)
ProxyPreserveHost Off
RequestHeader setifempty X-Forwarded-For "%{REMOTE_ADDR}s"
RequestHeader setifempty X-Real-IP       "%{REMOTE_ADDR}s"

# Keine Session-Cookies an den Besucher weiterleiten
Header always unset Set-Cookie

Zu aktivierende Module auf dem Server (bei seriösen EU-Hostern typischerweise bereits aktiv): mod_proxy, mod_proxy_http, mod_ssl, mod_rewrite, mod_headers.

Bei OVH Shared Hosting können Sie die Aktivierung beim Support anfragen — kostenlos und Standard.

Rezept 4 — Bunny.net Edge Scripting

Für wen: Traffic-starke Sites, die ein CDN-Edge näher am Besucher möchten (geringere Latenz + Entlastung des Ursprungsservers).

Europäische Präsenz: Bunny.net wird von BunnyWay d.o.o. in Slowenien betrieben. Wenn das Routing möglichst nah an Europa bleiben soll, begrenzen Sie die Pricing Zones bei der Einrichtung auf Europe.

Preise: ~0,01 €/Million Edge-Script-Anfragen + ~0,005 €/GB CDN-Bandbreite. Bei 1 Mio. Pageviews/Monat ca. 5 € gesamt. Kein Mindestabonnement, nutzungsbasierte Abrechnung.

Schritte:

Konto erstellen auf bunny.net (Kreditkarte, ~5 € kostenloses Startguthaben).
Eine „Pull Zone" erstellen:

Tab CDN → Schaltfläche Add Pull Zone
Name: ihrsite-snorklee (frei wählbar)
Origin URL: https://snorklee.com
Pricing tier: Standard
Pricing zones: Sie können nur Europe belassen, wenn Routing und Kosten auf diese Zone begrenzt bleiben sollen

Domain per CNAME verbinden:

Tab Hostnames → Add Hostname → flow.ihrsite.com
Bei Ihrem DNS-Registrar (Gandi, OVH usw.): CNAME flow.ihrsite.com → ihrsite-snorklee.b-cdn.net anlegen
5 Minuten warten, zurück zu Bunny → auf Generate Free SSL Certificate klicken (automatisches Let's Encrypt)

Pfad zuordnen:

Tab Edge Rules → Add Edge Rule
Action: Override URL
Match: Request URL contains "/js/flow.js"
Override URL: https://snorklee.com/w.js
Speichern

Finales Snippet:

<script defer src="https://flow.ihrsite.com/js/flow.js" data-site="ihrsite.com"></script>

Alle /api/*-Pfade werden automatisch über die Pull Zone an snorklee.com/api/* weitergeleitet.

Hinweis: Bunny gibt X-Forwarded-For standardmäßig korrekt weiter — damit prüfen wir die Identität der KI-Roboter. Die Länderkarte bleibt auf jeder weitergeleiteten Installation leer, siehe Kasten oben auf dieser Seite.

Rezept 5 — Next.js / Nuxt Rewrites

Für wen: Sites mit modernem JavaScript-Stack, deren Hoster Rewrites oder Server-Routen unterstützt.

Hosting: Prüfen Sie, dass Ihre Plattform die nützlichen Header (X-Forwarded-For, HTTP-Methode, User-Agent, Accept-Language) beibehält und dass die gewählte Ausführungsregion zu Ihren Datenschutz- und Performance-Anforderungen passt.

Mögliche Optionen sind klassisches Node/SSR-Hosting, Serverless mit expliziter Region, ein Docker-Container oder eine Frontend-Plattform mit serverseitigen Rewrites.

Next.js — in next.config.js:

module.exports = {
  async rewrites() {
    return [
      {
        source: '/js/flow.js',
        destination: 'https://snorklee.com/w.js',
      },
      {
        source: '/api/event',
        destination: 'https://snorklee.com/api/event',
      },
      {
        source: '/api/ping',
        destination: 'https://snorklee.com/api/ping',
      },
    ];
  },
};

Nuxt 3 — in nuxt.config.ts:

export default defineNuxtConfig({
  routeRules: {
    '/js/flow.js': { proxy: 'https://snorklee.com/w.js' },
    '/api/event': { proxy: 'https://snorklee.com/api/event' },
    '/api/ping': { proxy: 'https://snorklee.com/api/ping' },
  },
});

Next/Nuxt-Rewrites erhalten X-Forwarded-For und die HTTP-Methode automatisch. POST-Events werden korrekt weitergeleitet.

Hoster auswählen

Der First-Party-Proxy funktioniert mit vielen Hostern. Bevor Sie sich für eine Plattform entscheiden, achten Sie vor allem auf:

die Ausführungsregion, die der Proxy tatsächlich nutzt;
die Aufbewahrungsdauer der Logs beim Hoster;
die korrekte Weitergabe von X-Forwarded-For (sie dient der Identitätsprüfung von KI-Robotern, nicht der Verortung Ihrer Besucher);
die Möglichkeit, unnötige Cookies oder Header zu entfernen;
die vertraglichen Zusagen, die Sie für Ihre eigene Privacy-Policy benötigen.

Überprüfen, ob alles funktioniert

Das Skript lädt — öffnen Sie https://ihrsite.com/js/flow.js in Ihrem Browser: Sie sollten den minimierten Snorklee-Code sehen (beginnt mit !function()...).
Events werden gesendet — öffnen Sie DevTools (F12) → Tab Network und navigieren Sie auf Ihrer Website. Sie sollten eine Anfrage POST /api/event sehen, die mit 204 No Content antwortet.
Was Sie nicht sehen werden — auf einer weitergeleiteten Installation bleibt die Karte Länder leer und die eindeutigen Besucher sind Näherungswerte. Das ist so erwartet und kein Konfigurationsfehler (siehe Kasten oben auf dieser Seite); keine Proxy-Einstellung ändert das heute.
Das Ergebnis im Tab Integration — die Sonde „Installation testen" erkennt den Self-Host-Modus von selbst und zeigt „1st-party-Proxy erkannt" im Ergebnis an.

Häufig gestellte Fragen

Verlangsamt der Proxy meine Website? Nein, oder kaum. Der flow.js-Code ist ≈ 2 KB gzip und bleibt im Browser-Cache. Events gehen über sendBeacon raus, das nichts blockiert — der Besucher merkt keinen Unterschied, selbst wenn der Proxy 50 ms hinzufügt.

Was passiert, wenn mein Proxy ausfällt? Die Events aus dieser Zeit gehen verloren (keine Offline-Warteschlange — bewusst so, §25 TDDDG / DSGVO-Datensparsamkeit). Ihre Website selbst läuft normal weiter; nur die Besuchermessung pausiert. Wie bei jedem anderen ausgefallenen Drittanbieter-Dienst (Google Analytics, Plausible usw.).

Kann ich nur das Skript weiterleiten und nicht die API? Ja, mit dem Attribut data-api:

<script defer src="/js/flow.js" data-site="ihrsite.com" data-api="https://snorklee.com"></script>

Das Skript wird 1st-party ausgeliefert (es entgeht Blockern, die nach Dateiname filtern), aber die Events gehen direkt zu snorklee.com, wo Blocker, die nach Domain filtern, sie erneut blockieren. Das ist eine Abwägung, keine halbe Sache: Sie verlieren den blockierten Teil der Besuche und behalten dafür das Land Ihrer Besucher und verlässliche eindeutige Besucher — was das vollständige Weiterleiten nicht zurückgeben kann.

Was, wenn ich später mein Analytics-Werkzeug wechseln möchte? Die Proxy-Struktur bleibt gleich; Sie tauschen nur die Ziel-Domains aus. Der Code <script src="/js/flow.js" data-site="..."> bleibt überall derselbe.

Hilfe benötigt?

🛠️ Tab Integration im Dashboard → Schaltfläche Installation testen (automatische HTTP-Sonde)
📧 DSB/Support-Kontakt: siehe Tab Konformität im Dashboard
📚 Vollständige Dokumentation: /docs

Den Snorklee-Code über Ihre eigene Domain ausliefern (Anti-Blocking)

#WordPress — nehmen Sie das offizielle Plugin

#Funktionsweise — Schematische Übersicht

#Rezept 1 — Nginx (das universellste)

#Rezept 2 — Caddy (das einfachste)

#Rezept 3 — Apache (mod_proxy)

#Rezept 4 — Bunny.net Edge Scripting

#Rezept 5 — Next.js / Nuxt Rewrites

#Hoster auswählen

#Überprüfen, ob alles funktioniert

#Häufig gestellte Fragen

#Hilfe benötigt?