A failed connection is the report telling you where its coverage stops. Sometimes it also reveals a real problem, but the category alone never identifies the cause.
Read these rows before you read anything reassuring elsewhere in the report. They are what tells you which clean-looking sections were actually measured.
The six categories
| Category | What it narrows it to | What to investigate |
|---|---|---|
| DNS Resolution Errors | The name could not be resolved for inspection | Whether the name still exists, DNS health, and whether this is a historical discovery entry |
| Private Address Resolution | The name resolved to a private or internal address, which is not inspected | Whether that is intentional. If so, assess it internally instead |
| Connection and Timeout Errors | The connection did not complete or the listener did not respond | Firewall policy, routing, availability, stale addresses |
| TLS Handshake Errors | TLS negotiation could not complete | Protocol compatibility, TLS config, special client requirements |
| Certificate Errors | The certificate or chain failed validation | Hostname coverage, dates, issuer trust, missing intermediates |
| Other Errors | Did not fit a more specific category | The exact error text and the endpoint involved |
Do not promote a gap into a diagnosis
Every row above is a narrow statement, and every one of them gets over-read:
- A DNS failure does not prove a name is permanently gone. Lookups fail temporarily.
- A timeout says nothing about your certificate.
- A handshake error says nothing about your certificate either, because the certificate check never ran.
- A private address resolving privately is usually correct behavior, not a finding.
The one that matters most: an endpoint that failed the handshake has not passed the cipher, protocol, and certificate checks. It skipped them. Those sections will look empty rather than red, which is the opposite of how they read. Missing and inconclusive results covers the pattern in general.
Work one endpoint at a time
Write down the scan date, hostname, IP address, port, and the full error text. Compare against the deployment you expect, then try the same connection from a network comparable to the scanner’s.
If one address out of four fails, the problem is that node or that route. Do not reconfigure all four.
Once you have fixed the cause, retest and confirm the endpoint now produces usable evidence rather than a different error. If the service was deliberately retired, check your DNS cleanup and expect the historical name to keep appearing in discovery anyway. See scan coverage.