Hi, I have what I believe to be a specific networking error in your infrastructure to report. I will present findings below; the concrete implication of the issue is that some (spec-compliant) browsers are unable to complete the TLS handshake with 66.33.22.11 and will time out negotiating the connection.

I initially noticed that I was unable to load https://station.railway.com on my laptop (Pop!_OS 22.04, Firefox 135.0.1). I tested on my other laptop, running Ubuntu 24.04, and found the same result. I also provisioned an Ubuntu virtual machine and found the same result in both Firefox and Chromium. I tested both my residential internet connection as well as a mobile hotspot, with identical findings.

However, connections to the server worked fine from my phone (Android 15, GrapheneOS) and a Macbook. Furthermore, curl worked fine for all devices; this was something that affected browsers exclusively (but not something coming from configuration or plugins; I tested in an isolated Firefox profile, as well as from within the freshly provisioned VM).

I used Wireshark on my laptop and tcpdump on my router (OpenWrt) to look at what was actually happening at the protocol layer. The results were surprising. My client sends a SYN packet, gets SYN/ACK back, sends its own ACK, so the TCP three-way handshake is completed. It then sends a TLS ClientHello packet, which (due to modern browsers' use of the TLS key sharing extension) is much larger than the ClientHello used by curl, and in particular exceeds 1500 bytes. The TCP payload is automatically segmented by the Linux networking stack into two segments (1:1448 and 1449:1905); note that a TCP segment of 1448 octets corresponds to an encapsulated IP datagram of 1500 bytes. This should be fine, since your server is negotiating an MSS of 1460, corresponding to MTU of 1500 - and I can verify with ping -s1472 that 66.33.22.11 accepts 1500-byte ICMP frames just fine. Nonetheless, what comes back from the server is a TCP selective ACK (SACK) for only the 1449:1905 segment. The OS then repeatedly retransmits the initial 1448-octet segment, to no avail. So, the server accepts 1500-byte ICMP frames, but not 1500-byte TCP frames, contrary to the negotiated MSS.

tcpdump excerpt: https://paste.sr.ht/~raxod502/0b0f11b027b511fa39d2eb166546e34bad261c9d

I have an in-house tool for making network requests with custom TLS ClientHello fingerprints, and verified that if I make my own request from the command line that would trigger TCP segmentation, it reliably reproduces the error, contrary to curl's default options which all fit in a single packet. I also verified that if I manually decrease the MTU of my outbound network interfaces to less than their default of 1500, then full network connectivity to https://station.railway.com magically starts working in a browser.

I also checked router traffic while a working client, such as the aforementioned Macbook, was making a request. It sends the same segments initially, and they are blackholed in exactly the same way - but after several retransmits, it seems Apple's network stack decides to unilaterally decrease the MSS it uses, perhaps specifically to cope with issues like this one; it starts segmenting the payload into even smaller packets, which are then delivered successfully.