Skip to content

Fix NPE when bedrock HAProxy clientAddress is null#6429

Closed
lucas-santoro wants to merge 1 commit into
GeyserMC:masterfrom
lucas-santoro:fix-bedrock-haproxy-null-address
Closed

Fix NPE when bedrock HAProxy clientAddress is null#6429
lucas-santoro wants to merge 1 commit into
GeyserMC:masterfrom
lucas-santoro:fix-bedrock-haproxy-null-address

Conversation

@lucas-santoro
Copy link
Copy Markdown

After #6390 moved HAProxy handling into cloudburst-netty, RakServerChannel#getClientAddress can return null when no PROXY header has been cached for a sender. This happens on the first packet from a new sender, an expired session-cache entry, a malformed header, or a PROXY v2 LOCAL frame (which the upstream RakProxyServerHandler currently mishandles by passing null source addresses into InetSocketAddress).

Geyser passed that null straight through to onConnectionRequest, where clientAddress.toString() threw NullPointerException and the connection was dropped with a noisy stack trace, leaving operators without a useful diagnostic.

This change:

  • Adds an early null check in onConnectionRequest that rejects the connection cleanly and logs a WARN per occurrence when use-haproxy-protocol is enabled, pointing operators at the most likely upstream-proxy misconfiguration. RakNet's existing per-IP and global packet rate limiting (RAK_PACKET_LIMIT, DefaultRakServerThrottle) caps the realistic log rate.
  • Drops pings silently in RakPingHandler when no client address is resolved, so the server visibly appears offline instead of leaking the proxy's address to ping passthrough.

After GeyserMC#6390 moved HAProxy handling into cloudburst-netty,
RakServerChannel#getClientAddress can return null when no PROXY header
has been cached for a sender. This happens on the first packet from a
new sender, an expired session-cache entry, a malformed header, or a
PROXY v2 LOCAL frame (which the upstream RakProxyServerHandler currently
mishandles by passing null source addresses into InetSocketAddress).

Geyser passed that null straight through to onConnectionRequest, where
clientAddress.toString() threw NullPointerException and the connection
was dropped with a noisy stack trace, leaving operators without a useful
diagnostic.

This change:
- Adds an early null check in onConnectionRequest that rejects the
  connection cleanly and logs a WARN per occurrence when
  use-haproxy-protocol is enabled, pointing operators at the most
  likely upstream-proxy misconfiguration. RakNet's existing per-IP and
  global packet rate limiting (RAK_PACKET_LIMIT,
  DefaultRakServerThrottle) caps the realistic log rate.
- Drops pings silently in RakPingHandler when no client address is
  resolved, so the server visibly appears offline instead of leaking
  the proxy's address to ping passthrough.
@valaphee
Copy link
Copy Markdown
Member

valaphee commented May 31, 2026

Hey, thanks for the PR!

Packets without preceding proxy protocol header are already rejected, it's just that RakConnectionRequestHandler is put at first. The easiest fix would be to just move it before the RakServerOfflineHandler, like in #6436

This is also why it doesn't occur on ping, as ping is after the RakServerOfflineHandler

@valaphee
Copy link
Copy Markdown
Member

valaphee commented Jun 1, 2026

superseded by #6436

@valaphee valaphee closed this Jun 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants