Understand the targets' health checks

Understanding the targets' health checks will make it easier to troubleshoot.


Understanding HTTP targets' health checks

If the targets are HTTP servers, a health check is performed for all targets by sending a OPTIONS request to them. For a target to be marked as green, it must respond with either a 20X or 30X status code.

If the targets are marked as red, you can test whether they are responding with the correct HTTP status code using curl. In the example below, 203.0.118.89 is the IP address of one of the targets.

Command
curl -v -X OPTIONS http://203.0.118.89
Output
* processing: http://203.0.118.89
*   Trying 203.0.118.89:80...
* Connected to 203.0.118.89 (203.0.118.89) port 80
> OPTIONS / HTTP/1.1
> Host: 203.0.118.89 
> User-Agent: curl/8.2.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Tue, 14 Nov 2023 17:52:04 GMT
< Server: Apache/2.4.57 (Debian)
< Allow: GET,POST,OPTIONS,HEAD
< Content-Length: 0
< Content-Type: text/html

Here, you received HTTP/1.1 200 OK from the server, which means the target will be marked as functional with a green dot.

Understanding TCP targets' health checks

If the targets are TCP services, a simple TCP check will be performed as a health check.

You can manually try to connect your target's port with netcat (nc). This allows you to make sure the target is responding on the port. Let's assume the target's IP address is 203.0.113.57 and the port the service is running on is 9090. Run the command:

If the service is running on port 9090 and responding, you should get an output similar to this:

However, if the service is not responding on port 9090, you'll instead see an output like this:

Last updated

Was this helpful?