24 days ago
Hi,
My Celery worker service can resolve external DNS successfully
via socket.gethostbyname but cannot establish TCP connections
on port 443 to external APIs.
My Django web service on the same project reaches the same
external endpoints without any issues. Only the worker service
is blocked.
Project: cozy-flow
Failing service: celery-worker
Working service: analysis-agent (Django web service)
Both services are in the same Railway project. DNS works on
the worker but outbound HTTPS connections fail with
"Connection error" every time.
Is there a setting to enable outbound internet access for
worker/background services? Or is this a known limitation?
Diagnostic Evidence:
- DNS resolution test: PASSED (
api.anthropic.com→160.79.104.10) - TCP connection test: FAILED (connection timeout/refused on port 443)
- Same API key works from local machine
- Same endpoint works from analysis-agent web service
Thank you
1 Replies
Status changed to Open Railway • 24 days ago
11 days ago
There isn't a separate "enable outbound internet" switch for worker/background services on Railway. A worker service should be able to open outbound TCP connections just like a web service; public networking / a generated domain is only for inbound traffic.
Because DNS works but TCP/443 fails only from celery-worker, I would treat this as service-specific configuration rather than a Railway limitation:
1. Compare variables between analysis-agent and celery-worker, especially HTTP_PROXY, HTTPS_PROXY, NO_PROXY, SSL_CERT_FILE, REQUESTS_CA_BUNDLE, Anthropic base URL variables, and anything your HTTP client reads automatically.
2. SSH into / run a shell command in the worker and test raw TCP separately from your app code:
python -c "import socket; socket.create_connection(('api.anthropic.com',443),10); print('ok')"
Then test TLS/application layer with curl -Iv https://api.anthropic.com or the equivalent from the same container.
3. If the raw TCP test times out only in this service, redeploy the worker and try temporarily moving it to the same region/runtime settings as the working web service.
4. If the external API is filtering by source IP, enable Railway Static Outbound IPs on the worker service specifically and allowlist that IP. Railway documents static outbound IPs as per-service and applied after redeploy: https://docs.railway.com/reference/static-outbound-ips
The key point: you do not need a public domain for outbound access. Railway's serverless docs also treat outbound requests as normal service traffic, which is another hint that background services can make outbound internet calls: https://docs.railway.com/reference/app-sleeping