Recovery update — I restarted airtag-tracker at 2026-08-15 13:47 UTC.

The service recovered immediately

The new instance’s Apple-bound traffic is no longer showing IP_RPFILTER. Before the restart, Railway network logs recorded 148 dropped TCP/443 flows to gateway.icloud.com; post-restart flows are completing without that drop cause.

This confirms the outage was tied to the previous instance/network path. Please investigate the IP_RPFILTER drops and confirm the durable platform-side resolution.

Additional symptom: Google OAuth was also affected.

Between 2026-08-15 13:30:13 and 13:32:15 UTC, five consecutive Google login attempts reached our callback but then returned users to the login page.

GET /auth/google/login completed normally (303 in 3–26 ms). After the user selected their Google account, /auth/google/callback took approximately 10 seconds (10,019–10,094 ms) before returning 303 to /login.

Application log for each attempt:

oauth google login failed: token exchange failed: [Errno 101] Network is unreachable

The failing operation is the server-side POST to:

https://oauth2.googleapis.com/token

which exchanges Google’s authorization code for tokens. No user session could be created, so the app redirected back to login.

This is not consistent with a bad OAuth redirect URI, client ID, or client secret: those failures should reach Google and return an HTTP error. Here the application failed locally while opening its outbound network connection.

After restarting airtag-tracker at 2026-08-15 13:47 UTC, a direct request from the new instance to the same Google token endpoint reached Google immediately (returning the expected HTTP 400 when sent without an authorization code). Google login connectivity therefore recovered with the restart.

Please correlate this Google OAuth egress failure with the prior instance’s Apple-bound TCP/443 flows dropped with IP_RPFILTER, and investigate the old instance/network path.

This really looks like an instance/network-path issue rather than anything specific to Apple.

IP_RPFILTER means the kernel dropped the packet because reverse-path validation failed. The part that makes this especially convincing is that Google OAuth egress was failing on the same instance too, then both Apple and Google started working immediately after the restart.

So I don't think I'd spend time changing DNS, Apple allowlists, OAuth config, etc. The common point is the old Railway instance/network path.

If it happens again, restarting/redeploying is probably the right immediate mitigation since that already moved you onto a working path.

For the actual root cause though, I think Railway would need to inspect the old instance/host. I'd give them the old deploymentInstanceId plus a few of the dropped flow IDs and timestamps.

You can also pull just the affected flows with something like:

railway logs --network \
  --direction egress \
  --drop-cause IP_RPFILTER \
  --json \
  --since 2026-08-14T08:30:00Z \
  --until 2026-08-15T13:47:00Z

The useful fields there should be flowId, deploymentInstanceId, source/destination IPs and the capture timestamps.

Since the replacement instance immediately stopped producing IP_RPFILTER, I'd say the restart already confirmed the practical recovery path.

I don't think anyone outside Railway can really confirm the durable platform-side fix though, because that would require looking at the routing/rp_filter state on the old host.