The addresses you're seeing aren't any of the three Static IPs assigned to the service, so the running deployment is still sending traffic through the regular outbound addresses. Static Outbound IP changes only apply to new deployments, so the service needs to be redeployed after Static IPs are enabled before outbound traffic switches to the assigned addresses (docs).

We couldn't confirm from here whether the current deployment started before or after you turned Static IPs on. If it started after, please share the exact UTC time you saw requests from those other addresses.

It was 07 Nov 2026 at 01:00 UTC

The deployments currently running for this service in both its production and staging environments were created on 06 Nov 2026 at 22:04 UTC, which is before the 01:00 UTC requests you saw. If Static IPs were turned on after 22:04 UTC on 06 Nov, those deployments are still using the regular outbound addresses, and a redeploy is needed before traffic moves to the three assigned IPs.

The service also runs in two environments, and Static Outbound IPs are managed per environment. If the requests came from the environment that is not shown in your screenshot, that environment's settings are the ones to check. railway outbound-network static-ip status --service ai-lead-search --environment <name> shows the status for each one (CLI reference).

The service has been redeployed multiple times after the update, so it doesn't help

You're right, the service has been redeployed several times since, most recently on 13 Nov 2026 at 10:44 UTC, and Static IPs are enabled on it, so a missing redeploy doesn't explain what you're seeing. Our earlier reply's redeploy suggestion doesn't apply here.

The addresses you listed are not the three Static IPs assigned to the service, and we haven't yet found why outbound traffic is leaving from them. To trace specific requests, please share the destination host the requests went to, and the exact UTC time of at least one request that came from a non-static address after 10 Nov 2026.