Network connectivity issues on EUR–IS nodes (works fine on EUR–RO)
Hi Runpod team,
I’m running the same workload across different regions, and I’ve observed consistent connectivity problems when using the EUR–IS nodes, while everything works perfectly fine on EUR–RO nodes.
Symptoms:
My service makes HTTPS calls to https://freesound.org/apiv2/....
On EUR–IS nodes, connections often fail with ConnectTimeoutError at the TCP connect stage (before TLS/HTTP).
On EUR–RO nodes, the exact same code, container, and API key run without any issue.
Troubleshooting performed:
Confirmed DNS resolution: freesound.org resolves only to IPv4 (84.89.139.206) — no IPv6 involved.
Using curl -v from EUR–IS nodes shows repeated connection timeouts to the Freesound API, while EUR–RO nodes connect immediately and return valid JSON responses.
TLS certificates and Supabase connections from the same pod work fine, so general outbound egress is not blocked.
This strongly suggests a routing / peering issue specific to EUR–IS → Freesound’s network.
Impact:
Services relying on EUR–IS nodes cannot reach the Freesound API reliably, causing job failures. Switching to EUR–RO resolves the issue.
Request:
Could you please check the outbound connectivity / routing from EUR–IS nodes to 84.89.139.206:443 (freesound.org)? If possible, could you also confirm whether Freesound’s network is reachable from your monitoring?
Thanks for looking into this
I’m running the same workload across different regions, and I’ve observed consistent connectivity problems when using the EUR–IS nodes, while everything works perfectly fine on EUR–RO nodes.
Symptoms:
My service makes HTTPS calls to https://freesound.org/apiv2/....
On EUR–IS nodes, connections often fail with ConnectTimeoutError at the TCP connect stage (before TLS/HTTP).
On EUR–RO nodes, the exact same code, container, and API key run without any issue.
Troubleshooting performed:
Confirmed DNS resolution: freesound.org resolves only to IPv4 (84.89.139.206) — no IPv6 involved.
Using curl -v from EUR–IS nodes shows repeated connection timeouts to the Freesound API, while EUR–RO nodes connect immediately and return valid JSON responses.
TLS certificates and Supabase connections from the same pod work fine, so general outbound egress is not blocked.
This strongly suggests a routing / peering issue specific to EUR–IS → Freesound’s network.
Impact:
Services relying on EUR–IS nodes cannot reach the Freesound API reliably, causing job failures. Switching to EUR–RO resolves the issue.
Request:
Could you please check the outbound connectivity / routing from EUR–IS nodes to 84.89.139.206:443 (freesound.org)? If possible, could you also confirm whether Freesound’s network is reachable from your monitoring?
Thanks for looking into this
