4 months ago
My service couldn't reach api.mailjet.com (Mailjet's Send API) for ~18 hours. Diagnosis from inside the container:
- Egress IP at the time: 152.55.184.153
- TCP to api.mailjet.com:443 (35.187.79.8, a GCP LB) connects, but the peer sends a TCP RST immediately after the TLS ClientHello, handshake never completes. 100% of attempts, reproducible with plain curl:
- Trying 35.187.79.8:443...
- Connected to api.mailjet.com (35.187.79.8) port 443 (#0)
- TLSv1.3 (OUT), TLS handshake, Client hello (1):
- Recv failure: Connection reset by peer
- HTTPS to other hosts (google.com, api.github.com) from the same container worked fine, only Mailjet was affected.
- From outside Railway, the same Mailjet edge IP (35.187.79.8) completes the handshake normally. So this is source-IP-based blocking of 152.55.184.153 at Mailjet's edge, most likely IP reputation from another tenant sharing it.
Workaround that worked: a redeploy rolled my container to a different egress IP, where Mailjet handshakes fine. A restart alone did NOT change the IP.
Has anyone had similar issues?
1 Replies
4 months ago
Shared egress IPs on the Hobby plan can change on each deploy, and any of them may be affected by third-party reputation filters, which is what happened here with Mailjet. The Static Outbound IPs feature (available on the Pro plan) assigns permanent outbound IPs to a service so you can whitelist them with providers, though the docs note those IPs may still be shared with other customers.
Status changed to Awaiting User Response Railway • 4 months ago
4 months ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 4 months ago