nc ... Operation timed out means the TCP handshake to the public proxy never completed. This happens before database authentication, TLS, or an application connection string is evaluated, so changing credentials will not fix this symptom.

Start by copying the proxy hostname, external port, and configured internal port from the service's current Settings -> Networking -> TCP Proxy panel. Do not rely on an old saved value. Railway generates a hostname and external port for a proxy, and the configured internal port must be the port on which the service is actually listening.

From the same Mac that currently fails, run:

host='<current Railway TCP proxy hostname>'
port='<current Railway TCP proxy external port>'

dig +short A "$host"
dig +short AAAA "$host"
nc -4 -vz -w 10 "$host" "$port"
nc -6 -vz -w 10 "$host" "$port"

Then repeat the IPv4 test once with VPN/security software disabled and once through a phone hotspot or another network. This gives a useful result matrix:

• Hotspot works but the normal network times out: the local firewall, VPN, office proxy, or ISP is blocking the generated high TCP port. Allow outbound TCP to the current proxy host and port; Railway cannot change that local policy.
• Both networks time out, but DNS resolves: verify that the TCP Proxy still exists, its external port is unchanged, the target deployment is active, and the service is listening on 0.0.0.0:<internal-port> rather than only 127.0.0.1.
• IPv4 works while IPv6 fails: use the IPv4 result for the client and include both results if Railway needs to inspect the proxy's IPv6 path.
• DNS or the displayed host/port differs from the saved connection string: update the local connection string to the values currently shown in Railway.

Railway exposes the same three values to the service as RAILWAY_TCP_PROXY_DOMAIN, RAILWAY_TCP_PROXY_PORT, and RAILWAY_TCP_APPLICATION_PORT. You can print only the domain and port names from the Railway Variables UI to compare them, but do not post the database password or full connection URL.

If the client is another service inside the same Railway project and environment, do not route it out through the public TCP proxy. Use the service's RAILWAY_PRIVATE_DOMAIN and the application's internal port. The public proxy is appropriate for the laptop, which cannot resolve Railway private DNS.

Official references:

• TCP proxy setup and external/internal port behavior: https://docs.railway.com/networking/tcp-proxy
• Railway-provided proxy variables: https://docs.railway.com/variables/reference
• Private versus public networking: https://docs.railway.com/networking/public-networking

If the current endpoint times out from two unrelated public networks while the deployment is active and listening on the configured internal port, post the sanitized results plus the TCP proxy domain/port and exact UTC time. That is enough for Railway to inspect the proxy route without exposing database credentials.