Servez le code Snorklee depuis votre domaine (anti-blocage)

Chrome 121+, uBlock Origin, Brave Shields, AdGuard et la plupart des bloqueurs de pub bloquent par défaut tout appel vers un domaine extérieur étiqueté « analytics » — même quand le service ne fait aucune publicité ni aucun tracking publicitaire, ce qui est notre cas.

Si vous ne faites rien, vous perdez aujourd'hui 5 à 20 % de vos visites, et ça montera à 30-50 % d'ici 12 à 24 mois, quand Chrome étendra sa Tracking Protection à toutes les sessions (pas seulement la navigation privée).

La solution : servir le code Snorklee et l'API depuis votre propre domaine. Le navigateur voit alors un appel « 1st-party », impossible à distinguer du chargement d'une image ou d'une feuille de style. Là, aucun bloqueur ne le bloque.

Cette page vous montre comment faire, avec des configurations 1st-party qui collent à une infrastructure européenne. Choisissez l'hébergeur et la région d'exécution selon vos besoins de conformité, de performance et de support.

WordPress — passez par le plugin officiel

Sous WordPress, ne vous lancez pas dans Nginx, Caddy ou le DNS. Le plugin officiel Snorklee Analytics 2.3.4+ fait déjà tout le travail :

Installez ou mettez à jour le plugin depuis le dashboard Snorklee ou la page Plugin WordPress Snorklee.
Dans wp-admin, ouvrez Snorklee.
Vérifiez le domaine du site et laissez l'URL du dashboard sur https://snorklee.com, sauf instance auto-hébergée.
Activez Self-host mode puis enregistrez.
Lancez Tester l'installation. Le résultat doit indiquer self-host ou proxy 1st-party détecté.

Le plugin sert /js/flow.js depuis WordPress, relaie /api/event et /api/ping, garde le code JavaScript en cache 1 heure (via la Transients API) et ne stocke aucun événement dans WordPress.

Comment ça marche, schéma général

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

┌──────────────────────────────────────────────────────────────────────────┐
│                                                                          │
│   APRÈS (1st-party via votre proxy, jamais bloqué)                       │
│   ────────────────────────────────────────────                           │
│                                                                          │
│   navigateur ──► <script src="/js/flow.js"> sur monsite.com              │
│                  ✅ servi par votre proxy depuis snorklee.com         │
│                                                                          │
│   navigateur ──► POST monsite.com/api/event                              │
│                  ✅ relayé par votre proxy vers snorklee.com          │
│                                                                          │
└──────────────────────────────────────────────────────────────────────────┘

Vous relayez le script et 2 endpoints API depuis votre domaine vers snorklee.com :

Chemin sur votre domaine	Cible chez snorklee	Rôle
`/js/flow.js`	`snorklee.com/w.js`	Script du tracker
`/api/event`	`snorklee.com/api/event`	Pageviews + événements custom
`/api/ping`	`snorklee.com/api/ping`	Heartbeat « live » toutes 30 s

Le code à coller dans votre <head> devient :

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

Tous les chemins sont 1st-party : vu du navigateur, rien ne part vers un domaine extérieur. C'est votre proxy qui, côté serveur, fait le pont avec snorklee.com sans que le visiteur voie quoi que ce soit.

Ce que le relais coûte — l'adresse du visiteur : quand votre serveur relaie /api/event, c'est lui que nous voyons, jamais le navigateur. L'adresse que vous transmettez dans X-Forwarded-For nous parvient, mais nous refusons de la géolocaliser : sur un point d'entrée public, n'importe qui pourrait déclarer l'adresse de son choix. Sur une installation relayée, il n'y a donc ni pays ni région, et les visiteurs uniques deviennent peu fiables (ils sont dérivés de cette même adresse : des visiteurs distincts fusionnent). Ce n'est pas la seule mesure touchée : l'identifiant de visite dérive de cette même adresse, donc l'attribution des sources, la distinction direct/IA, les visiteurs en direct et l'engagement deviennent eux aussi peu fiables, et le plafond anti-abus (50 requêtes par minute et par adresse) s'applique désormais à tout votre site d'un coup. Les pages vues et les passages de robots, eux, restent comptés. Snorklee vous le signale dans la file de décisions au lieu d'afficher une carte fausse. Gardez quand même X-Forwarded-For dans les recettes ci-dessous : c'est lui qui permet de vérifier l'identité des robots IA. Si la carte compte plus que l'anti-blocage, relayez seulement le script (voir la FAQ en bas de page).

Recette 1 — Nginx (la plus universelle)

Fonctionne sur : tout VPS Linux (OVH, Scaleway, Hetzner, Clever Cloud avec runtime Nginx, IONOS, Infomaniak, etc.).

Souveraineté : neutre (dépend de votre hébergeur ; choisissez UE).

Ajoutez ce bloc dans votre fichier de configuration Nginx, à l'intérieur du server { ... } qui sert votre site (typiquement /etc/nginx/sites-available/monsite.conf) :

# snorklee — proxy 1st-party (anti-blocage)
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;
}

Puis testez et rechargez :

sudo nginx -t && sudo systemctl reload nginx

Pour vérifier : ouvrez https://monsite.com/js/flow.js dans votre navigateur — vous devez voir le code Snorklee minifié. En cas d'erreur 502, vérifiez que proxy_ssl_server_name on; est bien là (indispensable pour le SNI vers snorklee.com).

Recette 2 — Caddy (la plus simple)

Fonctionne sur : tout serveur où Caddy tourne (auto-TLS inclus).

Souveraineté : neutre (dépend de votre hébergeur).

Dans votre Caddyfile, à l'intérieur du bloc de votre site :

monsite.com {
    # ... votre config existante ...

    # snorklee — proxy 1st-party (anti-blocage)
    @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
        }
    }
}

Puis :

caddy reload --config /etc/caddy/Caddyfile

Syntaxe Caddy 2.6+ : on utilise un matcher nommé (@snorkleeApi path …) pour appliquer handle à plusieurs chemins. La forme handle /a /b /c { … } n'est pas acceptée par le parser et fait échouer caddy validate.

Caddy injecte X-Forwarded-For et X-Real-IP automatiquement, c'est pourquoi on n'a pas besoin de les déclarer explicitement comme avec Nginx.

Recette 3 — Apache (`mod_proxy`)

Fonctionne sur : hébergement mutualisé OVH, Infomaniak, IONOS, et tout serveur Apache avec mod_proxy activé. Utile pour les sites WordPress sur cPanel sans accès root.

Souveraineté : neutre.

Dans votre .htaccess (à la racine du site) ou <VirtualHost> :

# snorklee — proxy 1st-party (anti-blocage)
SSLProxyEngine On

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

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

# Préserver l'IP visiteur (setifempty pour ne pas écraser un XFF amont
# si vous êtes derrière un autre LB/reverse-proxy qui en pose déjà un)
ProxyPreserveHost Off
RequestHeader setifempty X-Forwarded-For "%{REMOTE_ADDR}s"
RequestHeader setifempty X-Real-IP       "%{REMOTE_ADDR}s"

# Ne jamais transmettre de cookie de session côté visiteur
Header always unset Set-Cookie

Modules à activer sur le serveur (typiquement déjà actifs sur les hébergeurs FR sérieux) : mod_proxy, mod_proxy_http, mod_ssl, mod_rewrite, mod_headers.

Sur OVH mutualisé, demandez l'activation à votre support si nécessaire — c'est gratuit et standard.

Recette 4 — Bunny.net Edge Scripting

Pour qui : sites à fort trafic qui veulent un CDN edge plus proche du visiteur (gain de latence + offload du serveur d'origine).

Implantation européenne : Bunny.net est édité par BunnyWay d.o.o. en Slovénie. Si vous voulez garder le routage au plus près de l'Europe, limitez les zones de pricing à Europe lors de la configuration.

Pricing : ~0,01 €/million de requêtes Edge Script + ~0,005 €/GB de bande passante CDN. Pour 1M pageviews/mois, comptez ~5 € total. Pas d'abonnement minimum, paiement à l'usage.

Étapes :

Créer un compte sur bunny.net (carte bancaire, ~5 € de crédit initial gratuit).
Créer une « Pull Zone » :

Onglet CDN → bouton Add Pull Zone
Name : monsite-snorklee (libre)
Origin URL : https://snorklee.com
Pricing tier : Standard
Pricing zones : vous pouvez ne garder que Europe si vous voulez limiter le routage et les coûts à cette zone

Connecter votre domaine en CNAME :

Onglet Hostnames → Add Hostname → flow.monsite.com
Chez votre registrar DNS (Gandi, OVH, etc.) : créer un enregistrement CNAME flow.monsite.com → monsite-snorklee.b-cdn.net
Attendez 5 min, retournez sur Bunny → cliquez Generate Free SSL Certificate (Let's Encrypt automatique)

Mapper le chemin :

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

Snippet final :

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

Tous les /api/* passent automatiquement vers snorklee.com/api/* via la Pull Zone.

Note : Bunny transmet X-Forwarded-For par défaut, ce qui permet de vérifier l'identité des robots IA. La carte des pays, elle, reste vide sur toute installation relayée — voir l'encadré en haut de page.

Recette 5 — Next.js / Nuxt rewrites

Pour qui : sites en stack moderne JavaScript dont l'hébergeur supporte les rewrites ou routes serveur.

Hébergement : vérifiez que votre plateforme conserve les headers utiles (X-Forwarded-For, méthode HTTP, User-Agent, Accept-Language) et que la région d'exécution choisie correspond à vos besoins de confidentialité et de performance.

Exemples possibles : hébergement Node/SSR classique, serverless avec région explicite, container Docker ou plateforme frontend qui expose des rewrites côté serveur.

Next.js — dans 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 — dans 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' },
  },
});

Les rewrites Next/Nuxt préservent automatiquement X-Forwarded-For et la méthode HTTP. Les events POST passent correctement.

Choisir son hébergeur

Le proxy 1st-party marche avec beaucoup d'hébergeurs. Avant d'en choisir un, regardez surtout :

la région d'exécution réellement utilisée par le proxy ;
la durée de conservation des logs côté hébergeur ;
la transmission correcte de X-Forwarded-For (elle sert à vérifier l'identité des robots IA, pas à situer vos visiteurs) ;
la possibilité de retirer les cookies ou headers inutiles ;
les engagements contractuels dont vous avez besoin pour votre propre politique privacy.

Vérifier que ça marche

Le script se charge — ouvrez https://monsite.com/js/flow.js dans votre navigateur : vous devez voir le code Snorklee minifié (il commence par !function()...).
Les événements partent — ouvrez les DevTools (F12) → onglet Network, puis cliquez sur une page de votre site. Vous devez voir une requête POST /api/event qui répond 204 No Content.
Ce que vous ne verrez pas — sur une installation relayée, la carte Pays reste vide et les visiteurs uniques sont approximatifs : c'est attendu, pas un défaut de configuration (voir l'encadré en haut de page). Aucune configuration de proxy ne change ça aujourd'hui.
Le résultat dans l'onglet Intégration — la sonde « Tester l'installation » repère toute seule le mode self-host et affiche « Proxy 1st-party détecté » dans le résultat.

Foire aux questions

Est-ce que le proxy ralentit mon site ? Non, ou à peine. Le code flow.js pèse ≈ 2 Ko gzip et reste en cache dans le navigateur. Les événements /api/* partent en sendBeacon, qui ne bloque rien : le visiteur ne voit aucune différence, même si le proxy ajoute 50 ms.

Et si mon proxy tombe en panne ? Les événements de cette période sont perdus (pas de file d'attente hors ligne — c'est un choix assumé, §25 TDDDG / minimisation RGPD). Votre site, lui, continue de tourner normalement : seule la mesure d'audience s'arrête. Comme n'importe quel autre service tiers en panne (Google Analytics, Plausible, etc.).

Puis-je relayer seulement le script, et pas l'API ? Oui, avec l'attribut data-api :

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

Le script passe en 1st-party (il échappe aux bloqueurs qui filtrent sur le nom de fichier), mais les événements repartent directement vers snorklee.com, où les bloqueurs qui filtrent sur le domaine les rebloquent. C'est un arbitrage, pas une demi-mesure : vous perdez la part de visites bloquées, et vous gardez en échange le pays de vos visiteurs et des visiteurs uniques fiables — ce que le relais complet, lui, ne peut pas restituer.

Et si je change d'outil d'analytics plus tard ? La structure du proxy ne bouge pas : vous changez seulement les domaines de destination. Le code <script src="/js/flow.js" data-site="..."> reste le même partout.

Besoin d'aide ?

🛠️ Onglet Intégration du dashboard → bouton Tester l'installation (sonde HTTP automatique)
📧 Contact protection des données/support : voir l'onglet Conformité du dashboard
📚 Documentation complète : /docs

Servez le code Snorklee depuis votre domaine (anti-blocage)

#WordPress — passez par le plugin officiel

#Comment ça marche, schéma général

#Recette 1 — Nginx (la plus universelle)

#Recette 2 — Caddy (la plus simple)

#Recette 3 — Apache (mod_proxy)

#Recette 4 — Bunny.net Edge Scripting

#Recette 5 — Next.js / Nuxt rewrites

#Choisir son hébergeur

#Vérifier que ça marche

#Foire aux questions

#Besoin d'aide ?