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:
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:
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:
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:
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:
<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
- Öffnen Sie Ihre Website in einem normalen Browser-Tab.
- Öffnen Sie DevTools → Network. Filtern Sie nach
/api/track. - Bestätigen Sie, dass jeder Request an Ihre eigene Domain geht (nicht an
analytics.flowsery.com). - 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 zummatcher-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 nichtresponse.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-ipusw.).