gobuster dir scan fails with "Error: unable to connect" to in-scope authorized host

TL;DR

Gobuster never reached the target: wrong scheme, wrong port, DNS failure, or a proxy env var blackholing the request. Curl the exact base URL from the tester box first; most of the time it is http vs https or a closed port.

Error: unable to connect

Use this when

• Gobuster dir mode fails immediately with unable to connect.
• The host is in scope and should be reachable.
• No requests from gobuster appear in target logs.

Not for this skill when

• The scan starts then drops connections. That is a timeout or rate problem.
• DNS resolves but the app 403s. That is a block, not a connection failure.
• The host is out of scope. Do not troubleshoot access to it.

Steps

1. Curl the exact base URL: curl -sI YOUR_TARGET_HOST/ | head -3. Verify: you get an HTTP status line.
2. Try the other scheme: if the https scheme fails, try the https scheme and vice versa. Verify: one scheme connects.
3. Confirm DNS and port: nslookup target and check the port is the one the app serves. Verify: the host resolves and the port is open.
4. Check proxy env vars: env | grep -i proxy. Gobuster respects them; a stale proxy blackholes lab targets. Verify: with proxies unset or --proxy set correctly, the connection works.
5. Rerun gobuster with the verified URL. Verify: the scan starts enumerating instead of erroring.

Variant phrasings

gobuster unable to connect dir

Compact phrasing.

gobuster connection refused scan

Alternate wording.

gobuster cannot reach target host

Symptom-level search.

Compatibility: gobuster v3.x on Linux, macOS, Windows. Proxy env handling is consistent across platforms.

Why it happens

"Unable to connect" fires at the TCP/TLS layer, before HTTP. The usual suspects in order: scheme mismatch (app is https-only), wrong port, DNS not resolving from the tester box, VPN down for internal targets, or proxy env vars from a previous engagement.

Edge cases / pitfalls

• Some targets only listen on a nonstandard port. Confirm the port from the engagement scope doc, not from habit.
• IPv6 vs IPv4 mismatches cause confusing failures; if DNS returns both, test each explicitly.
• A stale https_proxy is the classic repeat offender. Check env before you touch target config.
• If curl works but gobuster does not, compare their proxy settings; that gap is the entire bug.
• On Windows, check the firewall is not blocking gobuster specifically; curl passing while gobuster fails usually means per-app blocking.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_NurLj4-0waH5EpKu9tSwWw