bug: Gate NeoForge Login Disconnect With Large Modpacks Like ATM10sky

[Finn24-09]

Summary

Players attempting to join the atm10sky backend through Gate are dropped with
Connection Lost: Disconnected. Gate authenticates the client successfully, but the
connection is closed as soon as the backend starts streaming the NeoForge handshake
data. The tail of the Gate logs shows that the proxy crashes while trying to inflate
the first large LoginPluginMessage emitted by Proxy Compatible Forge:

2025-10-20T11:37:17.422Z … decoded packet … PacketType=*packet.LoginPluginMessage, Payloadlen=27
2025-10-20T11:37:17.452Z … decoded packet … PacketType=*plugin.Message,        Payloadlen=6979
2025-10-20T11:37:17.457Z … error reading packet, closing connection {"error": "error decompressing payload: unexpected EOF"}

Immediately afterwards the backend writes lost connection: Disconnected, because the
proxy has already torn down the socket:

[13:37:17] [Server thread/INFO] [minecraft/ServerConfigurationPacketListenerImpl]:
    … name=PLAYERNAME, … lost connection: Disconnected

Recommended config.yml was used, and the backend server has Proxy-Compatible-Forge V1.2.0 installed and configured.

[MiguVT]

Hey, this error usually means there's a problem with how Gate handles a large network packet during login.

To check if the issue is on Gate's side or somewhere else in the network, try using Velocity as a test proxy.
If it works with Velocity, the problem is probably with Gate. If it still fails, then it's likely a network or backend issue.

You can even do Gate -> Velocity -> Server as a temporary workaround to narrow down what's causing the disconnect.

Let me know if you want help testing or setting this up.

[MiguVT]

Also, have you tried adjusting some network settings?

For example, these defaults could affect large packets:

• mtu: Controls the maximum size of UDP packets (default 1400)
• use-direct-connection: Whether to attempt direct connections (default true)

try tweaking those values to see if it helps with the connection issue.

[Finn24-09]

Hi @MiguVT, thanks for your input on this problem. I've already tested with velocity proxy, which works just fine. The mentioned MTU settings seam to be dedicated to the bedrock setup of gate, as they're listed under the bedrock topic, which I'm not using. (https://gate.minekube.com/guide/config/)

To make velocity work, I have to adjust its JVM Arguments (JVM_OPTS: "-Dvelocity.max-known-packs=1024 -Dvelocity.packet-decode-logging=true") as players otherwise aren't able to join due to decoding issues on the proxy. Unfortunately, I can't find such settings or tweaks for Gate.

Many thanks and best regards.

[MiguVT]

Ok, thanks. that helps a lot.

I found a similar report for Velocity: PaperMC/Velocity#1404 this indicates it's a known problem in modded Minecraft proxies.

We should change:

• pkg/edition/java/proto/codec/decoder.go

Plan:

1. Add a small diagnostic log after reading the claimed uncompressed size to confirm if the compressed buffer is truncated.
2. Expose two config options (defaults = current values):
   • java.packetMaxFrameLength (default 1048576)
   • java.maxUncompressedSize (default = current UncompressedCap)
3. Validate and cap those values to a safe upper bound to avoid DoS.

Diagnostic snippet to add (near claimedUncompressedSize handling):

if d.log.Enabled() {
    d.log.Info("compressed packet meta",
        "claimedUncompressedSize", claimedUncompressedSize,
        "compressedBytes", buf.Len(),
        "compressionThreshold", d.compressionThreshold,
    )
}

If nobody picks this up, I will fork and open a PR (diagnostic-first, then config + validation + tests).

Sorry for my English, ask if anything is unclear. <3

[robinbraemer]

Go ahead and debug it. But not to only add this log line, but with the fix :)