Add Sentry tunnel to bypass ad-blocker on test environment

Co-authored-by: Junie <junie@jetbrains.com>
2026-07-25 15:40:14 +02:00
parent b7617d968d
commit f650c01c3e
4 changed files with 38 additions and 0 deletions
@@ -35,6 +35,24 @@ server {
        root /var/www/certbot;
    }

+    # Sentry "tunnel" endpoint (see src/main.tsx's Sentry.init tunnel option).
+    # Browser ad-blockers/privacy extensions commonly block requests that go
+    # straight to *.ingest.<region>.sentry.io (ERR_BLOCKED_BY_CLIENT), since
+    # that looks like third-party tracking. By forwarding this path server-side
+    # to Sentry instead, the browser only ever talks to our own domain
+    # (test.slpsoftware.nl), so it is no longer recognized/blocked as
+    # third-party tracking.
+    #
+    # LET OP: de org-/project-id in de proxy_pass hieronder MOET overeenkomen
+    # met de VITE_SENTRY_DSN die voor DEZE omgeving is ingesteld (de
+    # `VITE_SENTRY_DSN` Gitea repository variable voor de testomgeving). Pas
+    # dit aan als je ooit van Sentry-project/DSN wisselt.
+    location /sentry-tunnel {
+        proxy_pass https://o4511795618185216.ingest.de.sentry.io/api/4511795622838352/envelope/;
+        proxy_set_header Host o4511795618185216.ingest.de.sentry.io;
+        proxy_ssl_server_name on;
+    }
+
    location / {
        proxy_pass http://192.168.1.103:80;
        proxy_set_header Host $host;
@@ -25,6 +25,7 @@ Both the console and Sentry are now active (original Question 3 resolved as a co
 - **Manual follow-up required**: create a free Sentry project (https://sentry.io) for this app, copy its DSN, and set it as the `VITE_SENTRY_DSN` repository variable in Gitea (Repository Settings → Actions → Variables). Until that variable is set, the build still succeeds and the site still works — Sentry reporting simply stays inactive.
 - Free tier limits (error volume, retention) are typically sufficient for a low-traffic marketing site.
 - **Not (yet) implemented, by explicit choice**: automatic source map upload (via `@sentry/vite-plugin`), which the official Sentry setup guide also recommends so stack traces show real source code instead of minified code. This requires a Sentry auth token/org/project as a new Gitea secret; deliberately left out of scope for now — revisit if readable production stack traces become a priority.
+- **Ad-blocker mitigation via a Sentry "tunnel" (test/production only)**: requests straight to `*.ingest.<region>.sentry.io` are commonly blocked client-side by ad-blockers/privacy extensions (`ERR_BLOCKED_BY_CLIENT`), because they resemble third-party tracking. To avoid this in deployed environments, `Sentry.init()` sets `tunnel: '/sentry-tunnel'` (disabled — `undefined` — during local `pnpm dev`, where the ad-blocker itself is disabled instead, per earlier decision). The reverse-proxy Pi (`nginx/reverse-proxy-nginx.conf.example`) forwards that path server-side to Sentry's envelope endpoint, so the browser only ever talks to the first-party domain (e.g. `test.slpsoftware.nl`). This relies on full control over the reverse-proxy's nginx config, which is the case here (self-hosted on the user's own Raspberry Pi's) — it would not work on a third-party/shared host without reverse-proxy access. **Important**: the org-/project-id hardcoded in that nginx `location /sentry-tunnel` block must match whatever `VITE_SENTRY_DSN` is actually configured for that environment; update both together if the Sentry project/DSN ever changes.

 **Log level strategy**: only errors are logged (no verbose/info-level client logging) — this is a static site with no meaningful "business events" beyond page views, which are covered by analytics (see Dashboards below), not logging.