16 days ago
2 days ago, I could access my n8n dashboard (self-hosted GitHub version hosted on my Railway server). Had it set to sleep when inactive, simply took a trigger to wake it up and then it worked without issue.
Today, I'm completely blocked at the domain level. Will not load at all - EXCEPT in a private window in Safari. (Only have used the domain in Safari, but it would not load in Chrome in any type of window - so it's clearly not a browser-related issue).
Ran troubleshooting with Claude, after having issues with Railway's Agent not listening and changing settings around before I actually agreed to deploy them... so went external via MPC. (Also had Claude review the entire project & settings, found one small error with a variable name that had not impact on the key issue). As part of this, also thoroughly checked my network, proxies, et al for any potential reason it's being blocked.
Finally got something - but I cannot fix it on my end; it requires actual support to address. (And after rechecking with Railways Agent, they confirmed it requires actual support)
"Here's what I can confirm:
- This is a Railway infrastructure problem, not your machine or IP being "blocked" in the traditional sense
- The edge is rejecting your TLS Client Hello before the handshake completes
- Safari private works because it uses a different cipher suite order/extensions
- This requires Railway's infrastructure team to investigate and whitelist your TLS fingerprint
- Domain:qfr-n8n.up.railway.app
- Symptom: TLS Client Hello sent, server immediately FINs with 0 bytes returned
- Only Safari private works — all other clients rejected
- openssl s_client output: SSL handshake has read 0 bytes
- Your public IP: 47.72.125.165"
Really need this solved, as I have things running - and in the middle of setting up more n8n connections.
3 Replies
16 days ago
Your n8n service is running correctly on our end, with v2.19.3 listening on port 5678 and all workflows activated with no errors. We do not perform TLS fingerprint filtering, JA3 fingerprinting, or IP-based TLS blocking at our edge - no such system exists in our infrastructure - so the external AI's diagnosis about needing to "whitelist your TLS fingerprint" is incorrect and not something we can action on. Regarding the openssl s_client returning 0 bytes: your service has serverless (sleep) mode enabled, and the first connection to a sleeping service must wake it, which involves a cold boot; openssl s_client may time out during that wake period, producing exactly that result. The pattern of working only in Safari private windows but failing in regular sessions and other browsers points to cached client-side state (stale DNS, HSTS entries, SSL session tickets, or browser extensions) rather than server-side rejection, since private windows start with a clean slate. To help us investigate further from your network's perspective, we have a Network Diagnostics tool you can download and run, then share the output here.
Status changed to Awaiting User Response Railway • 16 days ago
Status changed to Open Railway • 16 days ago
16 days ago
Perhaps there are browser extensions or configurations blocking you from accessing the site?
16 days ago
The initial output was ran with the server ACTIVE - not sleeping.
But given that it runs fine in the private browser, the rest makes sense. However, we've checked everything possible on my side: network proxies, DNS, IP, extentions, et al. But a key point is that until now, I have never ran the n8n (or railway) in Chrome - it's always been via Safari. So it's not likely a browser-related issue if it crosses browsers. Have tested multiple options in Terminal, clearing caches, restarted laptop (done before I got Claude involved), the only thing left was server-issue. Even the Railway agent agreed with that outcome - though don't really trust your Agent right now. Only extension in Safari is SessionRestore - but disabled had no impact. I have more extensions in CHrome, but again - seems quite unlikely any of those would be blocking it from running.
Here's the diagnostic report from the tool:
Railway Network Diagnostics
Generated : Thursday, May 7 2026 03:06:42 NZST
Endpoint : routing-info-production.up.railway.app
-------------------------------------------------------------------------------
Client IP Info
-------------------------------------------------------------------------------
{
"ip": "47.72.125.165",
"hostname": "47-72-125-165.dsl.dyn.ihug.co.nz",
"city": "Whangarei",
"region": "Northland",
"country": "NZ",
"loc": "-35.7317,174.3239",
"org": "AS9500 One New Zealand Group Limited",
"postal": "0140",
"timezone": "Pacific/Auckland",
"readme": "https://ipinfo.io/missingauth"
}
-------------------------------------------------------------------------------
HTTP HEAD request
-------------------------------------------------------------------------------
Error: making HTTP HEAD request: Head "https://routing-info-production.up.railway.app": read tcp [2407:7000:ac6b:6300:2025:b442:ab64:598f]:53438->[2407:7000:2100:80ff:bd9d::1]:443: read: connection reset by peer
-------------------------------------------------------------------------------
DNS lookup (using system DNS)
-------------------------------------------------------------------------------
; <<>> DiG 9.10.6 <<>> routing-info-production.up.railway.app
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53165
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;routing-info-production.up.railway.app. IN A
;; ANSWER SECTION:
routing-info-production.up.railway.app. 10 IN A 203.96.208.40
;; Query time: 31 msec
;; SERVER: 2407:7000:ac6b:6300:a691:b1ff:fe43:87b0#53(2407:7000:ac6b:6300:a691:b1ff:fe43:87b0)
;; WHEN: Thu May 07 03:06:43 NZST 2026
;; MSG SIZE rcvd: 110
-------------------------------------------------------------------------------
DNS lookup (using Cloudflare)
-------------------------------------------------------------------------------
; <<>> DiG 9.10.6 <<>> @1.1.1.1 routing-info-production.up.railway.app
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21457
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;routing-info-production.up.railway.app. IN A
;; ANSWER SECTION:
routing-info-production.up.railway.app. 60 IN A 66.33.22.232
;; Query time: 127 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu May 07 03:06:43 NZST 2026
;; MSG SIZE rcvd: 83
-------------------------------------------------------------------------------
Traceroute
-------------------------------------------------------------------------------
1 ultrahub (192.168.1.1) 4.861 ms 4.342 ms
2 * *
3 unassigned.cust.vf.net.nz (203.96.208.49) 8.227 ms 7.869 ms
4 unassigned.cust.vf.net.nz (203.96.208.40) 6.990 ms 11.037 ms
-------------------------------------------------------------------------------
Ping (n=10)
-------------------------------------------------------------------------------
PING routing-info-production.up.railway.app (203.96.208.40): 56 data bytes
64 bytes from 203.96.208.40: icmp_seq=0 ttl=59 time=8.145 ms
64 bytes from 203.96.208.40: icmp_seq=1 ttl=59 time=8.296 ms
64 bytes from 203.96.208.40: icmp_seq=2 ttl=59 time=11.595 ms
64 bytes from 203.96.208.40: icmp_seq=3 ttl=59 time=8.300 ms
64 bytes from 203.96.208.40: icmp_seq=4 ttl=59 time=8.209 ms
64 bytes from 203.96.208.40: icmp_seq=5 ttl=59 time=8.307 ms
64 bytes from 203.96.208.40: icmp_seq=6 ttl=59 time=7.840 ms
64 bytes from 203.96.208.40: icmp_seq=7 ttl=59 time=8.006 ms
64 bytes from 203.96.208.40: icmp_seq=8 ttl=59 time=12.122 ms
64 bytes from 203.96.208.40: icmp_seq=9 ttl=59 time=7.996 ms
--- routing-info-production.up.railway.app ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 7.840/8.882/12.122/1.500 ms
Completed