an hour ago
Railway Support Request — Public TCP Proxy for PostgreSQL not accepting connections
## Subject
Postgres public TCP proxy (`gondola.proxy.rlwy.net:59848`) reports "ACTIVE" but does not
accept external TCP connections. Requesting review and restoration of the existing
public TCP proxy.
## Environment
- Workspace: ultimaxbariloche-lang's Projects
- Project: valiant-miracle (Project ID: 5f17b558-deb6-41c9-9ef2-4b9fd948bcb6)
- Environment: production (Environment ID: 5946d366-552d-4d7c-a7de-72872a8cade4)
## Affected resource
- Database: Postgres (Service ID: 5879ac19-62ac-4ff5-ac41-d2591267c524)
- Public TCP proxy:
- Proxy ID: b32ee70d-ee3c-40ac-a9df-b8c9e2e60985
- Endpoint: gondola.proxy.rlwy.net:59848
- Application port: 5432
- syncStatus: ACTIVE
- Created: 2026-03-27T05:07:41Z
## Problem summary
The public TCP proxy for the Postgres database reports syncStatus: ACTIVE in the Railway
API and the dashboard shows the database as "Online", but the endpoint does NOT accept
TCP connections from the public internet. Connections to gondola.proxy.rlwy.net:59848
time out at the TCP level.
## Evidence
1. PostgreSQL is up and reachable internally. A sibling service running inside Railway
(AkusBot) continues to read and write to this same Postgres without issues — its
scheduled sync jobs complete normally (e.g. "1064 productos guardados",
"1259 clientes guardados"). Only the public path is broken.
2. TCP connection timeouts from two independent external origins:
- LYON Bot Core VPS (187.77.39.32): 3/3 attempts fail with TCP timeout.
- A separate external host on a different network/ISP: also fails with TCP timeout.
3. DNS resolves correctly: gondola.proxy.rlwy.net → 66.33.22.247.
4. Database metrics are normal (last 24h): CPU < 0.01 vCPU (0%), Memory ~57 MB (1% of
8 GB), Disk 0.2 GB / 4.9 GB. No resource exhaustion or spike.
5. Railway status: the Postgres service shows "● Online".
## Impact
LYON Bot Core (our WhatsApp commerce bot) reads this Postgres as a read-only mirror of
the Cianbox product catalog. Because the public proxy is down, the bot cannot query the
catalog — its searches fail with mirror_no_accesible and customers receive a "try again
later" message instead of product availability. This is a production incident for us.
## Pending change on the same service (may be relevant)
There is exactly one pending operation on this environment:
- Type: EnvironmentPatch — ID: patch:77665dbe-df9e-426f-96ba-b7a16ea25761
- Change: resource.update on service 5879ac19-62ac-4ff5-ac41-d2591267c524 (Postgres)
- startedAt: 2026-11-04T11:11:56Z
- finishedAt: null (not applied)
- No actor recorded, no in-flight child deployments.
## Request
Please review and restore the existing public TCP proxy
(b32ee70d-ee3c-40ac-a9df-b8c9e2e60985 / gondola.proxy.rlwy.net:59848) so it accepts
external connections again.
For the avoidance of doubt: we have NOT restarted, redeployed, or updated the PostgreSQL
service, and we have NOT recreated or deleted the TCP proxy. We are reporting this as-is
and requesting that Railway review the proxy state.
No credentials are included in this report. 5 Replies
an hour ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 1 hour ago
an hour ago
Are there any errors in the Postgres? Have you tried redeploying the database or deleting and recreating the TCP proxy? (and make sure it’s forwarding to 5432).
Additionally, I’d recommend hosting your bot on Railway as well. Using the public network for your database can easily accumulate high egress costs.
an hour ago
Thank you for your response.
PostgreSQL appears to be healthy. Our internal application continues to access the database successfully, with no observed resource issues. The problem appears isolated to the public TCP proxy.
The existing proxy is already forwarding to port 5432.
We have not redeployed PostgreSQL or recreated the proxy yet, because this is a production database shared with other services.
Before proceeding, could you please clarify:
- Is deleting and recreating the TCP proxy the recommended solution for this specific issue?
- Will recreating it change the public hostname or port?
- Could Railway investigate the existing proxy, which reports ACTIVE but times out from two independent external networks?
We also have a pending EnvironmentPatch on the PostgreSQL service, which may be relevant.
We understand your recommendation regarding hosting the bot on Railway and will consider it separately.
Thank you.
an hour ago
Pending patches should not affect a service’s performance/behavior.
You could also try creating a second TCP proxy to test. (Recreating TCP proxies may provide different hostnames)
0x5b62656e5d
Pending patches should not affect a service’s performance/behavior. You could also try creating a second TCP proxy to test. (Recreating TCP proxies may provide different hostnames)
an hour ago
Thanks. I'd like to test a second TCP proxy without removing the existing one.
However, under Postgres → Settings → Public Networking, I can only see the existing TCP proxy, with copy and delete buttons. There is no option to add another.
Could you please tell me how to create a second TCP proxy for port 5432 without deleting the current one?
19 minutes ago
We have completed further network diagnostics.
The TCP proxy is reachable from a residential connection in Argentina, but connections consistently time out from two separate Hostinger servers:
- 187.77.39.32
- 187.77.34.182
Both fail to connect to gondola.proxy.rlwy.net:59848 (66.33.22.247).
A PostgreSQL SELECT 1 attempt also fails at the connection stage, before TLS negotiation or authentication.
DNS resolves correctly, PostgreSQL remains healthy, and internal Railway services continue accessing the database.
This suggests a network routing, filtering, or peering issue affecting connectivity between Hostinger and Railway.
Could Railway's networking team investigate reachability from the 187.77.x.x network to this TCP proxy?
We are also contacting Hostinger to investigate from their side.