== Summary ==

Outbound HTTPS from our container to a specific public IPv4 host

(165.227.126.241 — DigitalOcean) failed with EHOSTUNREACH persistently

for >24h and across ~4 redeploys, while the SAME host was fully

reachable from the public internet the whole time. DNS resolved

correctly inside the container. We changed only ONE variable — the

service region from US-West to US-East — and the problem resolved

immediately (confirmed both by our in-container probe and by our

external monitor normalizing). This points to a routing/egress problem

in the US-West region toward DigitalOcean, not our app or the

destination.

== Destination ==

Host: viacep.com.br -> 165.227.126.241

Network: DigitalOcean, LLC — 165.227.0.0/16 — AS14061 — US

Port: 443/HTTPS

== Controlled experiment (single variable changed) ==

Identical code, Node v24.10.0, same destination, DNS unchanged.

Only the Railway region changed: US-West -> US-East.

FROM CONTAINER, US-WEST (broken — representative samples):

2026-05-15 22:47:03Z HTTPS->165.227.126.241 EHOSTUNREACH (~76ms)

2026-05-15 23:15:02Z HTTPS->165.227.126.241 EHOSTUNREACH (~75ms)

2026-05-16 23:07:20Z HTTPS->165.227.126.241 EHOSTUNREACH (~76ms)

(persistent, >24h, ~4 redeploys; DNS A/AAAA resolved fine throughout)

FROM PUBLIC INTERNET (different network), same time windows:

curl -4 https://viacep.com.br/ws/01001000/json/ -> HTTP 200 (~0.4s)

ping 165.227.126.241 -> 3/3 packets, 0% loss, RTT ~131ms

FROM CONTAINER, US-EAST (after region change):

2026-05-17 16:18:18Z HTTPS->165.227.126.241 HTTP 200, 24ms (forced

IPv4) / 28ms (default). Problem gone, and ~10x lower latency than

US-West ever showed (US-West best case ~250ms).

== What we ruled out ==

• Not DNS: A (165.227.126.241) and AAAA resolve correctly in-container

  in both regions.

• Not the destination: globally reachable (HTTP 200 + ping 0% loss)

  during the entire US-West outage.

• Not IPv6: forced-IPv4 also failed in US-West (IPv6 is separately

  ENETUNREACH in both regions — expected, unrelated).

• Not our app/general egress: the service served traffic and other

  only from US-West.

== Questions / requests ==

1. Is there a known routing/peering issue or null route from the

   US-West region's egress to DigitalOcean AS14061 / 165.227.0.0/16?

   This may be affecting other US-West customers.

2. What egress/public IP(s) does the US-West region use for outbound

   IPv4 to that range, and is any of it being null-routed/blocked

   upstream or by the destination network?

3. The ~10x latency difference (US-West ~250ms vs US-East ~24ms to the

   same host) suggests an asymmetric/suboptimal US-West path — can you

   check transit/peering from US-West to DigitalOcean US?

4. Can you provide a stable/static egress IP per region (for future

   allowlisting and to make routing deterministic)?