CloudHub 2.0: EdgeIngress HTTP_Svrlet errRpt - 400 BAD REQUEST statusCode=17 failed state=MSV_RECEIVING

SYMPTOMS
In the ingress / Edge logs, the failing request shows a sequence similar to the following (values redacted):
  STARTLINE  POST /your-api-path/ HTTP/1.1
  HEADER     Host: api.example.com
  HEADER     ... (all headers parse successfully)
  errRpt - 400 BAD REQUEST statusCode=17 failed state=MSV_RECEIVING
  disconnect cause=DC_LOCAL_PROT_ERROR

Key characteristics:
- The TLS handshake completes successfully (this is not a certificate or TLS-version problem).
- All HTTP headers are parsed; the rejection occurs in the request-receive phase (MSV_RECEIVING).
- No response is returned by the application; the gateway returns a static 400 and closes the connection.

ROOT CAUSE
The hostname the client presents in the TLS handshake (the SNI, or Server Name Indication) does not match the Host header sent inside the HTTP request.

The CloudHub 2.0 ingress requires the SNI and the HTTP Host header to match. When they differ, the request is rejected at the ingress layer with the 400 error described above. This is intended platform behavior and is not configurable.

This is why standard clients succeed while certain clients fail: curl, Postman, and browsers automatically set the SNI to the same hostname used in the request URL, so SNI and Host always match. Some legacy or custom clients instead send an SNI that does not match the Host header, for example:
- a wildcard value (such as *.example.com), or
- the backend or origin hostname (such as an internal application hostname), or
- an empty or hardcoded SNI value.

HOW TO CONFIRM
Capture the client's outbound traffic (a packet capture on the client side is ideal, before TLS termination) and compare, for a failing request:
- the SNI in the TLS ClientHello, against
- the Host header sent in the HTTP request.
If the two do not match, this issue is confirmed. A working client captured the same way will show SNI and Host matching.