Load Balancing - Health - Debugging Failure Reasons

The Cloudflare Load Balancing API adds 'global' health to each Pool and origin server, which gives you a view into what our network sees at a wider level (currently: 70% quorum).

You can optionally get a per-data center breakdown of the health of your origins from our

GET user/load_balancing_analytics/events

API endpoint (see the documentation), which also provides the failure reason: why the health check actually failed.

Possible failure reasons include:

TCP connection failed

Our health checks failed to establish a TCP connection to your origin server. This typically occurs when there is a network failure between Cloudflare and your origin, and/or a firewall refused to allow our connection through.

HTTP timeout occurred

The origin failed to return a HTTP response within the timeout configured. If you have this set to a low number - 1 or 2 seconds - we recommend increasing it to allow your origin server to respond.

Response code mismatch error

We received a HTTP status code that did not match the expected_code of your Monitor configuration. Our health API returns the status in the ResponseCode field; make sure it matches. You may also see this if you have a Monitor configured to use HTTP and your origin server is re-directing to HTTPS; the response code will often be a 301, 302 or 303 instead. Either change your Monitor configuration to use HTTPS, or enable "follow_redirects" to allow us to resolve the correct status code.

Response body mismatch error

The response body returned from your origin server did not include the (case-insensitive) expected_body configured in your Monitor. Note that we only read the first 10KB of the response: if you return a larger response and the expected_body is not in the first 10KB, the health check will fail.

TLS untrusted certificate error

The certificate is not trusted by a public Certificate Authority (CA). If you're using a self-signed certificate, we recommend either using a publicly-trusted certificate, or setting "allow_insecure" on your Monitor to "true".

TLS name mismatch error

Our health check (client) was not able to match a name on the server certificate to the Hostname of the request. Check that any Host header set in the Monitor is correct.

TLS protocol error

Ensure that your server supports TLS 1.0 or greater, and is configured for HTTPS.

TLS unrecognized name error

The server did not recognize the name provided by the client. When a Host header is set, we set this as the ServerName in the initial TLS handshake. If not set, we will not provide a ServerName, which can cause this error. Set the Host header in your Monitor object.

No route to host

The IP address cannot be reached from our network. Common causes are ISP or hosting provider network issues (e.g. BGP level), or that the IP does not exist.



Not finding what you need?

95% of questions can be answered using the search tool. This is the quickest way to get a response.

Powered by Zendesk