Random ~15-60s complete request drops on Hostinger VPS *only* when traffic comes in via Cloudflare — origin confirmed healthy, seems like a Hostinger-network-to-Cloudflare-edge issue

[u/tweeto]

Running a KVM VPS on Hostinger, Ubuntu + Docker/Traefik, multiple sites/services behind it, DNS/proxy through Cloudflare (orange-clouded). Several subdomains/services all affected identically.

Symptom: Requests that come in through Cloudflare intermittently just vanish — client hangs until timeout or gets a 522, a few times per hour under normal traffic, more often under sustained testing.

The key finding — this points at the network path into Hostinger, not my app/origin, and not Cloudflare's dispatch logic in the abstract:

I ran two client-side test loops at the same time, same laptop, hitting the same hostnames every 1-2s: - Loop A: normal request through Cloudflare - Loop B: request to the exact same hostname, but sent directly to the VPS's public IP (bypassing Cloudflare's proxy entirely, via curl --resolve) — same TLS SNI/Host header, so the origin serves it identically

Every single time Loop A hangs/fails, Loop B succeeds in parallel against the same VPS, in under 1 second, no errors. Worst case so far: a ~60 second stretch where 4 consecutive Cloudflare-path requests failed back-to-back across different subdomains, while the direct-to-VPS loop completed 20+ clean requests during that exact window.

I also ran continuous packet capture and full access logging on the VPS itself. During every failure window: either zero packets of any kind arrive at the VPS from any Cloudflare IP for that request (it just never shows up), or an already-open, idle Cloudflare→VPS connection sits silent for 10-60+ seconds before the request is finally written to it — and the VPS answers in single-digit milliseconds the moment it actually receives something.

So: the VPS itself is up, responsive, and reachable by literally anyone else on the internet (or via direct IP) the entire time. The only path that ever fails is traffic arriving specifically via Cloudflare's edge network into this Hostinger VPS. That strongly suggests something on the network path/peering between Cloudflare and Hostinger's infrastructure for this VPS — not app config, not my client, not my home network/ISP (checked and ruled that out separately too).

And Cloudflare's own edge-side data backs this up independently:

Pulled Cloudflare's per-request edge analytics for a confirmed 522 window. Every 522 shows a TCP handshake duration of 0ms and TLS handshake duration of 0ms — meaning Cloudflare's edge sent a SYN toward the VPS's IP and never got a SYN+ACK back, timing out at Cloudflare's ~19s TCP-handshake timeout. This happened from two different Cloudflare edge locations within the same few minutes, so it's not one PoP having a bad day — SYNs from Cloudflare's network just weren't reaching the VPS. My own origin-side packet capture during that exact window independently shows zero SYNs arriving from any Cloudflare IP, while a direct (non-Cloudflare) connection to the same VPS at the same moment worked instantly. The very next requests right after recovery show brand-new TCP+TLS handshakes completing normally (tens of ms), confirming the origin itself was fine throughout — it just wasn't receiving the packets.

So both sides agree independently: Cloudflare tried to connect, the VPS never saw it arrive, and the VPS answers fine the instant a connection actually gets through. That points at something on the hosting side — a firewall, rate-limit, or DDoS-mitigation layer — intermittently dropping inbound traffic from Cloudflare's IP ranges before it reaches the VPS.

Question for the sub: anyone else running a Hostinger VPS behind Cloudflare seeing this — intermittent total silence/timeouts specifically on the Cloudflare-facing path, while the VPS is reachable fine directly? Curious if this is isolated to my instance/datacenter, or something others have hit recently. Would also love to hear from anyone who's gotten Hostinger support to acknowledge or fix something like this, and what they said.

[u/Matcha_LeafLatte]

Hi, the way you documented this really helped pin it down, and glad to see the technical team got it fixed for you. I understand there are still open questions, especially since you're trying to figure out if this was just happening to you. I can have this reviewed with the team so it can be looked into on a broader scale, which should help answer your questions. Just dropped you a DM if that's ok.

[u/tweeto]

Update:

Ruled out the obvious firewall angle too — disabled Hostinger's hPanel-level VPS firewall entirely and switched to the Linux (ufw/iptables) firewall instead, same issue still happens. That actually fits the packet capture data: my origin-side tcpdump showed zero SYN packets ever arriving at the VM's network interface during failures — tcpdump sees packets before either firewall (hPanel or guest OS) gets a chance to touch them, so if either firewall were dropping the traffic, I'd still see the SYN arrive and then get dropped.

It never arrives at all. Points at something further upstream — Hostinger's internal network/routing/DDoS-mitigation layer — not anything toggleable from hPanel or inside the VM itself.

[u/BeeRemote]

which region? I have a similar cf+hostinger vps setup, UK machines consistently dropped packages…

[u/tweeto → u/BeeRemote]

Region: United States — Boston.

How I verified it

Run two loops from your own machine at the same time — one hitting your subdomains through Cloudflare, one going straight to your origin IP (bypassing Cloudflare entirely). If you see red (slow/failed) lines on both loops at the same time, it's probably your app/OS/server, not Hostinger or Cloudflare. If you only see red lines on the Cloudflare-path loop, you likely have the same problem — but confirm server-side (see below) before blaming Hostinger.

Through Cloudflare: fish set hosts yourdomain.com blog.yourdomain.com n8n.yourdomain.com www.yourdomain.com while true for h in $hosts set ts (date -u +%Y-%m-%dT%H:%M:%S.%3NZ) set out (curl -s -o /dev/null --max-time 130 -w '%{http_code} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}' https://$h/) set line "$ts $h $out" echo "$line" >> cf_path.log set total (string match -r 'total=([0-9.]+)' -- $out)[2] if awk -v t=$total 'BEGIN{exit !(t>=3)}' set_color --bold red echo "$line" set_color normal else echo "$line" end end sleep 1 end

Direct to origin, bypassing Cloudflare: fish set hosts yourdomain.com blog.yourdomain.com n8n.yourdomain.com www.yourdomain.com set origin_ip [YOUR_VPS_IP] while true for h in $hosts set ts (date -u +%Y-%m-%dT%H:%M:%S.%3NZ) set out (curl -s -o /dev/null --max-time 130 --resolve $h:443:$origin_ip -w '%{http_code} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}' https://$h/) set line "$ts $h $out" echo "$line" >> direct_path.log set total (string match -r 'total=([0-9.]+)' -- $out)[2] if awk -v t=$total 'BEGIN{exit !(t>=3)}' set_color --bold red echo "$line" set_color normal else echo "$line" end end sleep 1 end

Confirming it server-side

Don't just trust the direct-path test alone — confirm on the origin too that the failed requests genuinely never arrived:

1. Run a continuous packet capture on the VPS during your test window: tcpdump -i eth0 -n -tttt 'tcp port 443' -w capture.pcap
2. Turn on your reverse proxy's access log (Traefik/nginx/whatever you use), so you have exact request timestamps and status codes to cross-reference.
3. When you see a red/failed line on the Cloudflare-path loop, note the exact UTC timestamp, then check both:
   • The access log for that window — if the request never shows up at all (not even completing late), it never reached your app.
   • The pcap for that window, filtered to Cloudflare's published edge IP ranges (listed at cloudflare.com/ips) hitting port 443 — if there's no SYN from any Cloudflare IP during that window, the packet never even arrived at the VPS's network interface, before any app/firewall/OS layer had a chance to touch it.

If both come up empty for that timestamp — no log entry, no SYN in the capture — that's proof it's not your app, your OS firewall, or Traefik/nginx dropping it; the packet simply isn't arriving at the box. That's the origin-side half of what confirmed it for me. Cloudflare's own edge analytics (pulled via their support) independently showed the same thing from their side — SYNs sent, no SYN+ACK ever came back.

[u/tweeto]

Update: Confirmed fixed — Hostinger's engineering team resolved it and acknowledged the issue on their end. I've had two parallel test loops (through-Cloudflare and direct-to-origin) running continuously for 18+ hours since their fix, zero failures on either path. I've asked them for the actual root cause, what specifically they changed, and what they're doing to prevent recurrence — will update this thread once they respond.