We do not filter or block outbound traffic on port 443 for Pro plan services. Your service's other egress connections to port 443 are completing normally, which confirms the network path from your container is functional. The timeout pattern you're seeing - SYN packets silently dropped with no response - is consistent with the destination (Moneris) filtering inbound connections by source IP. Payment processors commonly restrict access to allowlisted IPs, and your current egress IP is a shared address that would not be on their allowlist. You can enable Static Outbound IPs in your service's Settings under Networking, then provide that fixed IP to Moneris for allowlisting.

​Moneris has confirmed they do not whitelist or filter incoming requests by IP address for their Gateway API. This means the connection issue is occurring on the outbound side of your Railway service.

We do not block any outbound traffic on port 443. Your bounty is open for the community to help you debug this further.

Hello agausvik,

so based on what's confirmed railway isn't blocking, moneris isn't ip filtering, but the handshake still dies so the one thing nobody has tested yet is whether icmp is getting through between the two endpoints; can you run a tcpdump on your container while the connection attempt is happening and check if you're getting any icmp messages back, specifically "fragmentation needed"? that would tell us exactly where the packet is dying and why the handshake never completes

and can you confirm whether the tcp three-way handshake itself completes (syn, syn-ack, ack) before the tls handshake times out, or does it die before that?

TCP dies. We don't reach the TLS layer at all.

The diagnostic ran two separate probes back-to-back: a bare net.Socket().connect() with no TLS at all, and a separate full tls.connect(). They're independent sockets, so whatever the TCP-only probe shows is the truth about the TCP three-way handshake on its own.

Results for www3.moneris.com (23.249.192.193):

TCP-only :443 by hostname → timed out after 8000ms (no SYN-ACK received)

TCP-only :443 by literal IP → timed out after 8000ms (no SYN-ACK received)

TLS :443 → timed out after 12000ms (never got past TCP)

If TCP had completed and only TLS was failing, the bare TCP probe would have returned ok:true in a few milliseconds (SYN/SYN-ACK/ACK only takes one RTT) and only the tls.connect() would have stalled. That's not what we see. The bare TCP socket emits neither connect nor error, and waits the full 8-second timeout. Node only fires connect once SYN-ACK arrives and we send the final ACK; that event never fires. So our SYN is going out into the void. No SYN-ACK, no RST, no ICMP unreachable.

Compare to the same TCP-only probe against gateway.moneris.com (23.249.200.196, adjacent Moneris IP): completes in 3 ms. So the SYN-ACK pipe back from Moneris's network to us works fine for at least one of their IPs.

Net of all this: the SYN is being silently dropped somewhere on the path to 23.249.192.193 specifically. If it leaves you and dies in transit (or at Moneris's edge), we know exactly who to escalate to next.

unless you have something that comes to mind I am convinced its a Moneris issues. would you agree?

yes it's almost certainly moneris's side,

and here's why the data backs that up cleanly , so we have same egress ip, same railway container, tcp to gateway.moneris.com on a neighboring ip completes in 3ms no problem. tcp to 23.249.192.193 specifically gets silently dropped with zero response. that rules out railway's routing entirely. the problem is specific to that one ip. moneris needs to check if there's a firewall rule, acl, or load balancer config on that specific host that is silently dropping syns from your egress rang

Thank you I appreciate your insight

your welcome!