Author: catbox404 Environment: Android/Termux host + Arch Linux PC + playit tunnel Network: UTP hostel-style shared NAT (no port forwarding)

0. The “it works until it doesn’t” symptom set

What players saw:

  • join succeeds, then can’t break blocks / interact
  • random disconnects: keepalive timeout
  • things get worse during chunk loads / fast travel (elytra), i.e. when traffic spikes

What the server looked like:

  • TPS looked fine most of the time
  • so the server felt “healthy”, but clients still died

This combo usually means: network path instability, not pure CPU starvation.

1. Hypotheses we had (ranked by likelihood)

1) Wi‑Fi jitter / bufferbloat (dorm network behaviour under load) 2) Tunnel relay/routing variance (playit region/path changes) 3) Overlay/VPN weirdness (WARP messing with routes/DNS/firewall) 4) Host device limits (Android scheduling, backgrounding, thermal throttling) 5) Minecraft config / tick lag (only if TPS/MSPT bad)

We did not treat any of these as “truth” until we could A/B test.

2. What we measured (not just vibes)

2.1 “Is the server actually dying?” (tick health)

On the server:

  • /tps and MSPT
  • spark profiler when needed

Rule of thumb:

  • TPS stable but clients drop => path/jitter/relay issues more likely
  • TPS bad => server CPU/memory/plugins/chunk-gen issues

2.2 “Is the network lying?” (variance over averages)

We stopped caring about “11 ms speedtest”.

Instead:

  • watch max latency, spikes, and loss
  • test during the actual failure conditions (joining, chunk loads)

3. The turning point: topology A/B test

A) Baseline (bad-ish)

Phone/host rides dorm Wi‑Fi directly.

Result:

  • periodic instability
  • keepalive timeouts

B) PC hotspot as stabiliser (better)

PC on Ethernet to dorm LAN, phone connects to PC’s hotspot:

[Android Host] -- Wi‑Fi --> [PC Hotspot] -- Ethernet --> [Dorm LAN] --> Internet

Result:

  • fewer spikes
  • fewer disconnects
  • sessions felt more consistent

Interpretation:

  • this strongly implicates the dorm Wi‑Fi uplink/jitter, even if it doesn’t “prove” anything globally.

4. The “hotspot has no Internet” facepalm

At one point the hotspot was up but the phone had no Internet. This wasn’t magic; it was Linux being Linux.

Two common causes we saw evidence for:

4.1 Forwarding policy defaulting to DROP

If FORWARD policy is DROP and you don’t add the right ACCEPT rules, clients can associate but won’t route.

(We captured iptables -L FORWARD showing policy DROP + Docker chains only.)

4.2 Docker meddling / competing firewall state

Docker installs its own chains and can change forwarding defaults. Not “wrong”, just another moving part when you’re trying to do ICS/hotspot.

Operational fix (conceptually):

  • ensure IP forwarding is enabled
  • ensure NAT + forward rules allow hotspot subnet -> uplink interface
  • or let NetworkManager’s hotspot handle it (so you don’t hand-roll rules)

5. The WARP/VPN rabbit hole

When Cloudflare WARP was in the picture:

  • we saw routing/DNS oddities and connection resets
  • some HTTPS tooling showed certificate/handshake failures in a way that looked like “something in the middle” (not necessarily malicious; could be broken interception or mis-route)

When WARP was removed:

  • general connectivity normalised
  • hotspot behaviour improved

Conclusion: If you’re tunnel-hosting and running an overlay VPN, you’re stacking multiple routing layers. That’s asking for pain.

6. playit tunnel quirks (what we learned)

Tunnels can behave differently depending on:

  • which relay you’re assigned
  • transient route changes

Symptoms:

  • “it was fine yesterday”
  • relay region looks different
  • latency changes without you touching anything

How to handle it:

  • treat the tunnel as a variable
  • retest on the same local network before blaming your server

7. Final “adult” conclusion

What we know:

  • dorm Wi‑Fi produced periodic spikes under real usage
  • a topology swap (Ethernet uplink + PC hotspot) reduced instability
  • WARP/VPN layering made things worse

What we don’t claim:

  • “UTP Internet is bad” as a blanket statement
  • single root cause certainty

What worked:

  • optimise for jitter stability under load
  • minimise overlay complexity
  • use topology changes as the “big lever”, not Minecraft config tweaks

END