«An existing connection was forcibly closed by the remote host» sounds like a network fault, and it usually is not one — it is what a saturated networking thread looks like from the outside, once the connection it was supposed to be servicing has already given up waiting.
What Netty is doing under the hood
Minecraft's networking layer runs on Netty, an asynchronous I/O framework that hands packet reading and writing to a small pool of dedicated threads separate from the main game-logic thread. That separation is deliberate — it is what lets the server keep talking to two hundred clients without the world tick itself having to wait on any single slow connection.
That pool is still finite. If something generates packets faster than Netty's threads can serialise and send them — a scoreboard rewriting itself every tick for every player, a hologram plugin pushing metadata updates constantly, a burst of malformed packets from a client-side cheat — the outgoing queue backs up. A client whose connection has gone quiet for long enough assumes the server is gone and tears down the socket from its end, which the server then reports as the connection being forcibly closed, because from its point of view that is exactly what happened.
Common triggers
| Trigger | Why it saturates the network thread |
|---|---|
| Per-tick scoreboard or tab-list updates | Rewrites and resends structured data to every connected client, every tick |
| Hologram or floating-text plugins with many instances | Each one tracks nearby players and pushes entity metadata packets constantly |
| Skin/cape restoration loops | Repeatedly re-requests and re-broadcasts profile data instead of caching it |
| Malformed or excessive packets from a cheat client | Forces extra validation and processing per packet on the way in |
Because the error names a networking failure, it is easy to assume the edge or the firewall is at fault. The mitigation and routing layers sit in front of this entirely — the saturation happens inside the game process itself, between its own Netty threads and its own outgoing packet queue, which is why the fix is always in what the server is sending, not in network configuration.
/spark profiler report during the disconnects names the source directlyPacket-heavy plugins show up clearly in a profile as time spent in networking or packet-send code. That is a faster path to the cause than testing plugins one at a time by disabling them.