Troubleshooting HTTP health-checks failures in a reverse proxy when a forwarding 'default sequence' is configured.
Last Updated May 13, 2017
You have deployed a reverse-proxy with a 'default sequence' in your forwarding hosts configuration. Your Web servers are up and running and the TCP health-checks are working, but HTTP health checks are failing.
HTTP health-checks are subject to policy evaluation. Any request that does not have a specific policy instruction or a matching forwarding rule in policy, will use the default sequence defined in Configuration > Forwarding > Forwarding Hosts > Default Sequence.
Therefore, when you have a default-sequence enabled, you could see the following issues with HTTP health-checks:
HTTP health-checks fail, but TCP health-checks work.
You can successfully perform a 'test http get' from an SSH/Console session, but health-checks fail.
You can browse to the reverse-proxy sites through the proxy, but HTTP-health still fail.
The health-checks are failing due to a HTTP 404, but you know the document exists on the web-server.
The health-check statistics show the correct IP has been resolved by DNS, but a PCAP shows the ProxySG is connecting to the wrong IP (because the ProxySG is connecting to the default-sequence IP instead).
The ProxySG is attempting to perform all HTTP health-checks against only one of you HTTP servers, causing it to fail when it should be successful (or vice-versa).
To resolve the HTTP health check failures, you must do one of the following:
Option 1) Create a VPM rule in the Forwarding Layer that instructs the health check to to go direct instead of using the default sequence that you have defined in configuration.
The rule should look as follows:
Option 2) Delete the default sequence as follows:
Go to Configuration > Forwarding > Forwarding Hosts > Default Sequence.
Select the fowarding sequence from the Selected Aliasesgroup.
Imported Document ID: 000014102
Subscribing will provide email updates when this Article is updated. Login is required to Subscribe