Troubleshooting Tip: WebSocket traffic fails behind HTTPS Virtual Server in Azure Active/Active deployments

Description

This article describes an issue where WebSocket‑based applications fail when published through a FortiGate HTTPS Virtual Server in an Azure Active/Active deployment. The affected environment uses an Azure External Load Balancer (ELB) in front of the FortiGates and an Azure Internal Load Balancer (ILB) behind them. Standard HTTPS traffic works normally, but WebSocket upgrade requests fail when passing through the Virtual Server.

Scope

FortiOS.

Solution

• In Azure Active/Active topologies, HTTPS Virtual Servers use the WAD proxy engine to terminate and re‑establish connections to backend servers. When HTTP multiplexing is enabled on the VIP (set http-multiplex enable), the FortiGate may forward backend traffic using HTTP/2 pooled connections, even when the client uses HTTP/1.1.

• WebSocket applications require a strict HTTP/1.1 Upgrade handshake (Connection: Upgrade, Upgrade: websocket). When the FortiGate forwards this request over an existing HTTP/2 multiplexed backend connection, the backend server may reject the request because it does not support WebSockets over HTTP/2. This results in WebSocket handshake failures.

• The backend server typically responds with an error such as:

HTTP/1.1 400 Bad Request
server: <application server>

• Packet captures and WAD debug logs show that the FortiGate receives the WebSocket upgrade request correctly, but forwards it over an HTTP/2 stream.

• Debug logs may include messages such as:

wadhttpfullsesmake: switch to VS H2
wadh21waysrvtmpshmstrmclose
wadh21waytmpshmstrmprocmsgattachreal_shmstrm

These indicate that the Virtual Server is using HTTP/2 multiplexing toward the backend.

• The issue persists even when all security profiles (WAF, IPS, AV, SSL inspection) are removed, because the failure occurs at the WAD proxy layer before security inspection.

To ensure WebSocket compatibility, disable HTTP multiplexing on the HTTPS Virtual Server. This forces the FortiGate to use HTTP/1.1 end‑to‑end, allowing the WebSocket upgrade handshake to pass through correctly.

config firewall vip
    edit "<HTTPSVIPNAME>"
        set http-multiplex disable
    next
end

• This change does not interrupt existing sessions and takes effect immediately. 

• After applying the change, the backend server will receive a valid HTTP/1.1 WebSocket upgrade request and respond with 101 Switching Protocols.

• Azure Load Balancers operate at Layer 4 and do not modify WebSocket traffic; therefore, the issue is not caused by Azure ELB/ILB.  

• The problem occurs specifically when the FortiGate Virtual Server is configured in proxy mode and HTTP multiplexing is enabled.  

• WebSocket applications behind HTTPS Virtual Servers require HTTP/1.1 to be preserved end‑to‑end.

A related issue affecting WebSocket upgrade handling behind HTTPS Virtual Servers was resolved in:

• FortiOS v7.4.9.

• FortiOS v7.6.4.

These versions include fixes to WAD behavior when handling WebSocket upgrade requests in environments using HTTP/2 backend multiplexing:

• The fix is not present in the v7.2.x branch, including v7.2.12. 

• Environments running v7.2.x may experience intermittent or persistent WebSocket failures even with correct configuration.

Upgrading to a firmware version containing the fix is recommended for long‑term stability.