Skip to content

fix(web): locate views by X-Real-IP instead of the last forwarded hop - #23

Merged
hjescalona merged 1 commit into
smgfrom
feat/self-hosted-geoip
Nov 13, 2026
Merged

hjescalona merged 1 commit into
smgfrom
feat/self-hosted-geoip

Conversation

@hjescalona

Copy link
Copy Markdown

Why

After #21 and #22 deployed, a test view from 134.82.68.114 (Palm Bay, FL in DB-IP; Railway's HTTP log shows that same srcIp) was recorded as US / Florida / Miami. The request went through Railway's mia1 edge. clientAddress takes the last X-Forwarded-For hop off Vercel, and on Railway that hop is the edge's address, so every view would be located at the edge POP instead of the viewer.

What

  • The track route and the mobile view event look up getClientIp (X-Real-IP first, then the first X-Forwarded-For entry), the helper upstream already uses for self-hosted IP checks. Railway documents X-Real-IP as the client's address.
  • The route test now sends an X-Forwarded-For whose last hop is a different address and checks that the lookup uses X-Real-IP.

Verified

  • analytics-track-route, visitor-location, mobile-cap-view-notification tests pass; bun run typecheck clean.
  • After deploy: send one test view and check the city in Tinybird.

On Railway the last X-Forwarded-For entry is the edge's own address, so
every self-hosted view was located at the edge POP (Miami for a viewer in
Palm Bay). Use getClientIp, which reads X-Real-IP first, like the other
self-hosted IP checks.
@hjescalona
hjescalona merged commit 0081b89 into smg Nov 13, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant