## 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.

```text
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