Unterstützung/Proxy-Anleitungen
Proxy-Anleitungen

Flowsery Analytics mit Next.js proxyen

Leiten Sie Flowsery Analytics in einer Next.js-Anwendung über Ihre eigene Domain weiter, um Störungen durch Adblocker zu vermeiden und genaue Besucherdaten zu erfassen.

Ein vollständiger Proxy besteht in Next.js aus zwei Schritten: einem Rewrite (damit der Tracker wie First-Party-Traffic aussieht und Adblocker überlebt) und Middleware (damit die echte Besucher-IP an das Flowsery-Backend weitergegeben wird). Rewrites allein liefern zwar Events, aber jeder Besucher erscheint dann aus der Region Ihres Servers - Sie benötigen beide Schritte.

1. Rewrites konfigurieren

Fügen Sie in Ihrem Projektstamm next.config.js hinzu oder aktualisieren Sie die Datei:

JavaScript
module.exports = {
  async rewrites() {
    return [
      {
        source: '/js/main.js',
        destination: 'https://cdn.flowsery.com/main.js',
      },
      {
        source: '/api/track',
        destination: 'https://analytics.flowsery.com/analytics/events',
      },
      {
        source: '/:locale/api/track',
        destination: 'https://analytics.flowsery.com/analytics/events',
      },
    ];
  },
};

Wenn Ihr Projekt bereits /api/track verwendet, wählen Sie einen anderen Pfad und geben Sie ihn dem Tracker über data-api mit, zum Beispiel data-api="/flowsery-events".

2. Die echte Besucher-IP injizieren (Middleware)

Next.js-Rewrites führen einen Server-zu-Server-Fetch aus. Dabei ersetzt die nachgelagerte Cloudflare-Edge cf-connecting-ip durch die IP Ihres Next.js-Servers. Flowsery sieht dann jeden Besucher als "Ihren Server" und löst die Geodaten auf Ihre Hosting-Region auf.

Um das zu beheben, fügen Sie Middleware hinzu, die die echte Besucher-IP beim Eingang liest und in einen benutzerdefinierten Header x-flowsery-real-ip schreibt. Dieser Header übersteht den Proxy-Hop unverändert, und das Flowsery-Backend bevorzugt ihn gegenüber cf-connecting-ip, wenn er vorhanden ist.

Erstellen oder aktualisieren Sie middleware.ts im Projektstamm:

TypeScript
import { NextRequest, NextResponse } from 'next/server';
 
const TRACKING_PROXY_PATHS = /\/api\/track$/;
 
export default function middleware(request: NextRequest) {
  if (!TRACKING_PROXY_PATHS.test(request.nextUrl.pathname)) {
    return NextResponse.next();
  }
 
  const realIp = request.headers.get('cf-connecting-ip') || request.headers.get('x-forwarded-for')?.split(',')[0]?.trim();
 
  if (!realIp) return NextResponse.next();
 
  const forwardedHeaders = new Headers(request.headers);
  forwardedHeaders.set('x-flowsery-real-ip', realIp);
 
  return NextResponse.next({
    request: { headers: forwardedHeaders },
  });
}
 
export const config = {
  matcher: ['/api/track', '/:locale/api/track'],
};

Falls Sie bereits Middleware haben

Es gibt zwei Dinge, die Sie sauber zusammenführen müssen:

1. Der Handler. Führen Sie die Tracking-Proxy-Logik zuerst für /api/track-Pfade aus und lassen Sie danach Ihre bestehende Logik weiterlaufen:

TypeScript
export default function middleware(request: NextRequest) {
  // Runs for /api/track + /:locale/api/track. Returns a response only when
  // the path matches, otherwise returns NextResponse.next() so your existing
  // logic runs below.
  if (/\/api\/track$/.test(request.nextUrl.pathname)) {
    const realIp = request.headers.get('cf-connecting-ip') || request.headers.get('x-forwarded-for')?.split(',')[0]?.trim();
    if (realIp) {
      const headers = new Headers(request.headers);
      headers.set('x-flowsery-real-ip', realIp);
      return NextResponse.next({ request: { headers } });
    }
    return NextResponse.next();
  }
 
  // ...your existing middleware logic here (locale detection, auth, etc.)
}

2. Der Matcher. Viele page-level-Middleware-Konfigurationen verwenden einen negativen Lookahead wie /((?!api/|_next/...).*), um API-Routen auszuschließen. Dieses Pattern schließt auch /api/track aus, wodurch die Middleware für den Tracking-Pfad nie ausgeführt wird. Erweitern Sie das matcher-Array, um den Pfad ausdrücklich wieder einzuschließen:

TypeScript
export const config = {
  matcher: [
    // Your existing page-level pattern — leave it alone.
    '/((?!api/|js/|_next/static|_next/image|favicon.ico|locales|ingest).*)',
 
    // Added so middleware also runs for the tracking proxy paths.
    '/api/track',
    '/:locale/api/track',
  ],
};

Die Reihenfolge spielt keine Rolle. Die matcher-Einträge werden per OR verknüpft - ein Pfad löst Middleware aus, wenn irgendein Eintrag passt. Seitenrouten verwenden weiter Ihr bestehendes Pattern; /api/track trifft den neuen expliziten Eintrag und erreicht den Tracking-Proxy-Handler oben.

3. Skript-Tag anpassen

Zeigen Sie mit dem Skript auf den lokalen Proxy-Pfad:

HTML
<script defer data-fl-website-id="flid_******" src="/js/main.js"></script>

4. Deploy

Rewrite und Middleware werden beim Deploy aktiv.

Prüfen, ob es funktioniert

  1. Öffnen Sie Ihre Website in einem normalen Browser-Tab.
  2. Öffnen Sie DevTools → Network. Filtern Sie nach /api/track.
  3. Bestätigen Sie, dass jeder Request an Ihre eigene Domain geht (nicht an analytics.flowsery.com).
  4. Prüfen Sie im Flowsery-Dashboard, ob Länder und Städte der Besucher Ihrer Zielgruppe entsprechen und nicht Ihrer Hosting-Region.

Fehlerbehebung

Jeder Besucher scheint aus demselben Ort zu kommen

Wenn alle Besucher aus einer einzigen geografischen Region erscheinen (typischerweise der Region Ihres Servers), setzt der Middleware-Schritt den Header x-flowsery-real-ip nicht korrekt.

Häufige Ursachen:

  • Der Middleware-Matcher enthält den Tracking-Pfad nicht. Viele bestehende Matcher verwenden einen negativen Lookahead wie /((?!api/|...).*), der /api/* ausschließt. Fügen Sie /api/track (und /:locale/api/track, falls Sie sprachpräfixierte URLs verwenden) als explizite Einträge zum matcher-Array hinzu.
  • Sie haben den Header zur Response statt zum Request hinzugefügt. Das Backend liest Request-Header; verwenden Sie NextResponse.next({ request: { headers } }) und nicht response.headers.set(...).
  • Ihr Edge-Provider ist nicht Cloudflare. Wenn Sie hinter Vercel, Fly.io oder einer anderen Edge laufen, lesen Sie die Besucher-IP aus dem Header dieses Providers (x-real-ip, x-vercel-forwarded-for, fly-client-ip usw.).