[Bug] Source IP dependent handshake failure

[AtomicByte8]

Summary

The server closes the websocket for the GET /handshake request if the HTTP reverse proxy defined in sv_listingHostOverride does not forward traffic to the backend server from the same IP as the HTTP connect endpoint. There seems to be overly strict source IP verification between the two stages of the websocket handshake which breaks various configurations.

I assume this might cause problems even without sv_listingHostOverride if the source IP of a connecting player does not remain constant between TCP connections (e.g. ISPs that use CGNAT, Starlink, mobile data connections) - unconfirmed.

Example configuration using placeholder IPs and domains:

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

set sv_forceIndirectListing true
set sv_listingHostOverride "fivem.yourdomain.com"
sv_listingIpOverride "10.0.0.0"
sv_proxyIPRanges "10.0.0.0/24"
sv_endpoints "10.0.0.0:30120"

In this example, the FiveM server is hosted at 10.0.0.1 and the reverse proxy server is hosted at 10.0.0.0. The intention is that the FiveM client will connect to 10.0.0.0:443 as the HTTP connect endpoint, and TCP traffic destined for 10.0.0.0:30120 will be forwarded to the FiveM server at 10.0.0.1:30120 without the use of an HTTP reverse proxy on port 30120.

When connecting through the server list, the client sends a GET /challenge HTTPS request to 10.0.0.0:443 (TCP). This is forwarded to the FiveM server at 10.0.0.1:30120 (TCP) along with an X-Real-IP and X-Forwarded-For header containing the IP address of the HTTP client (player). All headers from the original request are forwarded to the backend.

After this, the client then sends the GET /handshake request to 10.0.0.0:30120, which is routed directly to 10.0.0.1 without the use of an HTTP reverse proxy.

The second request (GET /handshake) which is sent to TCP port 30120 will succeed only if the GET /challenge request and the GET /handshake request are forwarded to 10.0.0.1 from the same source IP, for example 10.0.0.5. If there is a load balancer or other system in place which may forward either the initial GET /handshake request or any subsequent TCP connections to port 30120 from different source/forwarding IPs, the handshake will fail with the following error:

Connection failed
Failed to connect to the server (Step 2.) Error: WebSocket handshake failed. Websocket closed.

If the HTTP requests sent to https://fivem.yourdomain.com and the subsequent TCP connection to 10.0.0.0:30120 are forwarded to 10.0.0.1:30120 from a different IP within the 10.0.0.0/24 range which was set in sv_listingHostOverride, the handshake will fail.

If everything is forwarded to 10.0.0.1:30120 from a fixed source such as 10.0.0.5, the handshake then succeeds.

See also #183 which may be a secondary issue that the client reaches if all traffic is forwarded from the same IP.

Issue type

Both / Unsure

Repro rate

Always

Server build version

FXServer-early-access b94 win32

OS

No response

CPU

No response

GPU

No response

RAM

No response

Storage type

None

Connection type

None

ISP and bandwidth

No response

DxDiag

No response

Network graph

No response

Platform

None

OS version / distribution

No response

CPU

No response

RAM

No response

Using txAdmin?

Yes

Hosting provider

None

Machine type

None

/perf endpoint output

No response

DDoS protection

No response

ulimit -n value (Linux only)

No response

Docker Compose file (Docker only)

No response

Steps to Reproduce

1. Follow the steps outlined at https://docs.fivem.net/docs/server-manual/proxy-setup (note this documentation may need to be updated for FiveM for GTA V Enhanced)
2. Load balance connections to the backend using different source IPs
3. Attempt to connect to the server through the server list
4. Observe that the websocket handshake fails

Expected Behavior

1. To enable players to connect if their ISP uses CGNAT or similar, the strict source IP validation might need to be reconsidered.

The connection should succeed if any of the following conditions are met in combination with an HTTP reverse proxy on https://fivem.yourdomain.com

2. To support various routing configurations, the FiveM server should accept the GET /handshake request on the basis that the source IP of the GET /handshake request is the same as the IP which was present in the X-Forwarded-For / X-Real-IP HTTP request headers in the GET /challenge request to https://fivem.yourdomain.com from sv_listingHostOverride.

3. To support a transparent TCP proxy, the FiveM server should accept the GET /handshake request if the source IP of the request is present in sv_proxyIPRanges.

Actual Behavior

The client fails to connect to the server.

Connection failed
Failed to connect to the server (Step 2.) Error: WebSocket handshake failed. Websocket closed.

Evidence

No response

Additional Context

No response

[wolfram-cfx]

Thanks, we are looking into this.

[FingerlessGlov3s]

I've got some players who can get in to the server and others who can't after b96 when using sv_listingHostOverride. So it's improved but still problematic in parts.

Gone back to not using sv_listingHostOverride for now

[wolfram-cfx]

Are all your proxies inside the proxy ip ranges? Can you verify that players who can not connect are coming from a proxy that is whitelisted.

[IchigoWalker]

Some findings from attempting a TLS-terminating same-host reverse proxy (a single nginx in front of the game port, so /challenge and /handshake both reach the server from one source IP) on the latest artifact (bXX, 2026-07-25) — may be useful context:

1. GET /challenge returns a signed message of the form 0;<nonce>;20;<observed-ip>;<port>, where <observed-ip> is the TCP peer address the server saw. Through the proxy that's the proxy's internal IP. The join then dies with "Connection to the host has been aborted: Handshake." even though both requests arrive from the same proxy IP — so the binding appears stricter than plain source-IP equality between the two requests (per-connection port in the signed message? client-side validation of the embedded address?).
2. We could find no mechanism to restore the real client address behind a proxy — no X-Real-IP / X-Forwarded-For / PROXY protocol handling appears to exist server-side. If reverse proxies are meant to be supported at all, some real-IP mechanism would be needed; if they're not, it might be worth documenting explicitly.
3. Separately, and probably worth a look on its own: the game port's TLS negotiates TLS 1.2 only and does not offer the secure-renegotiation extension, so stock OpenSSL 3.x clients abort the handshake with unsafe legacy renegotiation disabled (and a TLS 1.3 ClientHello gets alert 40). This breaks modern monitoring/health-check tooling against the game port regardless of any proxy questions.

To be clear, we're not asking to support MITM-style proxying of the connect flow — the address binding looks intentional and reasonable. Leaving this here so the constraints are documented for others attempting proxy setups, and because of point 3.

[wolfram-cfx]

Are your proxies forwarding using ipv6 maybe and the mapping doesnt map that correctly to a proxy?

[wolfram-cfx]

Also added tls 1.3 support for future patches. But I won't enable the secure-renegotiation extension.

[IchigoWalker]

Root cause found and confirmed fixed on our side. The failing layer wasn't the IP check at all — it was TLS: the Enhanced client's TLS stack rejects RSA server certificates during the wss handshake. With a default nginx TLS setup (RSA cert), the client sends a tiny TLS 1.2 ClientHello (~193 bytes), receives the server flight, and immediately aborts with fatal alert 40 (handshake_failure).

Mimicking the cfx-server's own TLS profile fixed it completely: self-signed ECDSA P-256 certificate (same subject shape as the autogenerated do-not-trust.citizenfx.tls.invalid one), ssl_protocols TLSv1.2, ssl_ecdh_curve prime256v1. With that, on b96, a same-host TLS-terminating nginx in front of the game port passes the full join — /challenge (plain HTTP), wss /handshake, and the resource downloads — and a shared nginx cache on /resources/* serves warmed resource.rpf/stream blobs to subsequent joins with hash verification passing (so response bytes are stable across sessions — nice!).

Two things that may be worth documenting for Enhanced proxy setups: the ECDSA requirement above, and that URL-keyed caches still have no invalidation signal (no ?hash=, per #146). Happy to share our nginx config if useful.

[Legacy-TacticalGamingInteractive]

Would you be so kind as to share your block for your Enhanced server nginx conf? I have tried on our end to do what you were able to do, but no luck here.

[IchigoWalker]

Would you be so kind as to share your block for your Enhanced server nginx conf? I have tried on our end to do what you were able to do, but no luck here.

Sure. Hope it works for you.

error_log /var/log/nginx/error.log info;   # TLS handshake failures (with alert code) log at info, not warn

events { worker_connections 4096; }

# FXServer serves plain HTTP *and* TLS on the one game port — reproduce that.
stream {
    map $ssl_preread_protocol $fivem_listener {
        ""      127.0.0.1:8080;   # no ClientHello -> plain HTTP
        default 127.0.0.1:8443;   # TLS ClientHello  -> terminate TLS
    }
    server {
        listen 30120;             # public game port
        ssl_preread on;
        proxy_pass $fivem_listener;
        proxy_protocol on;        # carry the real client IP across the loopback hop
        proxy_timeout 3600s;
    }
}

http {
    map $http_upgrade $connection_upgrade { default upgrade; '' ''; }
    resolver 127.0.0.11 valid=10s ipv6=off;    # Docker per-request DNS; drop if upstream is static

    server {
        listen 127.0.0.1:8080 proxy_protocol;
        listen 127.0.0.1:8443 ssl proxy_protocol;
        set $fivem_upstream fxserver:30120;    # where FXServer actually listens (NOT the public :30120)

        # THE FIX — mimic cfx-server's own game-port cert. The client rejects an RSA
        # cert with fatal alert 40, and rejects TLS1.3. Must be ECDSA P-256 (openssl below).
        ssl_certificate     /etc/nginx/tls/cert.pem;
        ssl_certificate_key /etc/nginx/tls/key.pem;
        ssl_protocols       TLSv1.2;
        ssl_ciphers         "ALL:@SECLEVEL=0";
        ssl_ecdh_curve      prime256v1;

        set_real_ip_from 127.0.0.1;            # restore real client IP from the PROXY header —
        real_ip_header   proxy_protocol;       # client drops /handshake if its IP != /challenge's (rfc#182)

        location / {
            proxy_pass http://$fivem_upstream;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;        # /handshake is a WebSocket
            proxy_set_header Connection $connection_upgrade;
            proxy_set_header Host $http_host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_buffering off;
            proxy_read_timeout 3600s;                      # connect WS sits idle for minutes during downloads
        }
    }
}

ECDSA cert:

mkdir -p /etc/nginx/tls && openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes -days 3650 -subj "/C=XX/CN=do-not-trust.citizenfx.tls.invalid" -keyout /etc/nginx/tls/key.pem -out /etc/nginx/tls/cert.pem && chmod 0600 /etc/nginx/tls/key.pem

[Gogsi]

A fix for this bug has been implemented and is available in the latest patch b96/97. Please try again and let us know if the issue persists. Thanks for your help!

[AtomicByte8]

Thank you! I have the following observations with FXServer-early-access b96 win32:

• The handshake now completes successfully if both steps originate from an IP within the scope of sv_proxyIPRanges
  • A transparent TCP proxy therefore works correctly
• If a form of encapsulation which preserves the client IP is used (such as a GRE tunnel), the handshake still fails unless you add 0.0.0.0/0 to sv_proxyIPRanges
  • I assume this is because the first request (GET /challenge) is sent to the FiveM server from an HTTP reverse proxy IP contained within sv_proxyIPRanges, but for the subsequent GET /handshake request which the client sends to TCP port 30120, the server sees the real IP that the client is connecting from, which could be any public IPv4 address.
  • If you add 0.0.0.0/0 to sv_proxyIPRanges, GET /handshake over the tunnel succeeds
  • But this likely defeats the purpose of sv_proxyIPRanges?

Perhaps the FiveM server should accept GET /handshake if the IP which was included in X-Forwarded-For or X-Real-IP during GET /challenge is later seen as the IP that GET /handshake appears to originate from.

The X-Forwarded-For or X-Real-IP header should likely only be trusted for HTTP requests originating from IPs under sv_proxyIPRanges.

I think this was the functionality in Legacy FiveM which was described at:

https://docs.fivem.net/docs/server-manual/proxy-setup

# a space-separated list of IPv4 networks in CIDR notation to allow 'X-Real-IP'
# from, as well as bypass the rate limiter
set sv_proxyIPRanges "100.64.1.1/32"

I can also confirm that #183 is still reproducible in FXServer-early-access b96 win32.

[Legacy-TacticalGamingInteractive]

I can confirm also still having issues on this with b106

[wolfram-cfx]

With what exactly? This is configuration depending so please provide more infos like in the original message.

[Legacy-TacticalGamingInteractive]

With what exactly? This is configuration depending so please provide more infos like in the original message.

I have tried mimicking both of the solutions attempted by Atomic and Ichigo, several hours of tinkering including with Cloudflare settings on tunnel. Reworking the nginx conf etc. With no luck at all. I can connect outside of the FiveM client just fine with cmd/powershell, returning do-not-trust.citizenfx.tls.invalid etc, with either setup they tried. But still Failed to connect to the server (Step 2.) Error: WebSocket handshake failed. Websocket closed from Enhanced client.

(I have no issues on FiveM legacy server setups, with any proxy setup, its only Enhanced. I am at a loss of what to try now.)