The proxy is reachable from external networks (nc -zv nyproxy10.proxydns.tech 5805 succeeds from my local machine).

The SOCKS5 proxy functions correctly outside Railway.

The connection is refused only when originating from my Railway service in the us-west (SFO) region.

Could you please verify:

Whether there are any outbound egress restrictions on TCP port 5805.

Whether traffic to 152.233.46.146 is being filtered or blocked.

Whether there are any firewall, abuse-prevention, or networking policies affecting outbound connections from this region.

If possible, whether you can check the network path or connection logs for attempts from my service to that destination.

Before concluding it's a Railway issue, I'd also recommend one check from inside your Railway container:

nc -vz nyproxy10.proxydns.tech 5805

or

telnet nyproxy10.proxydns.tech 5805

If nc inside Railway also returns Connection refused, that strongly suggests the destination (or its firewall) is refusing connections from Railway's public egress IPs, rather than Railway blocking outbound traffic. If it instead times out, then an egress filtering or routing issue becomes much more likely.

Yeah I'm getting similar results to the post above but I deployed a container to Railway in us-west (sfo), the same region as geelark-scheduler, and ran it.

For me nc -vz nyproxy10.proxydns.tech 5805 succeeded inside railway, so I don't think there is a egress filter on port 5805, and the proxy is not refusing Railway either, which makes things a bit confusing.

In your error the refusal only appears against the literal IP 152.233.46.146.** That address returns ECONNREFUSED in 67 ms. Meanwhile the hostname resolves to 64.78.254.177 today, on a different provider's network.

Seems like your vendor moved the endpoint, and I'm guessing your code is hardcoded for requests to 152.233.46.146, which is why the SocksClientError gives a failure at the first handshake.

Fix

1. Search your code and your Railway variables for the literal IP:

   
   152.233.46.146
   

   If you find it, use the hostname instead:

   
   const proxy = { host: "nyproxy10.proxydns.tech", port: 5805, type: 5 };
   

2. If you are already using the hostname, redeploy geelark-scheduler. A long-running process can hold on to the address it looked up at startup, and your scheduler has probably been running since before your vendor moved the endpoint. A redeploy forces a fresh lookup.

3. To see what your container actually resolves and reaches, run this at boot and check your deploy logs:

   
   import dns from "node:dns/promises";
   
   import net from "node:net";
   
   const host = "nyproxy10.proxydns.tech";
   
   console.log("resolves to:", await dns.resolve4(host));
   
   const s = net.connect({ host, port: 5805, timeout: 10000 });
   
   s.on("connect", () => { console.log("connected to", s.remoteAddress); s.destroy(); });
   
   s.on("timeout", () => { console.log("TIMEOUT"); s.destroy(); });
   
   s.on("error", (e) => console.log("failed:", e.code));
   

If that logs connected to 64.78.254.177, your egress is healthy and your fix is step 1 or step 2. If it prints a different address, it is worth asking your vendor for their current endpoint, since they have moved it once already.

If this ends up being the case it's good practice to not pin a proxy vendor's IP address anywhere in your config. Vendors rotate endpoints, and a pinned address turns that routine change into an error that looks like a network block. Using the hostname lets DNS follow them.

Happy building and looking forward to an update :)