nuclei "connection refused" on every authorized target in scope

TL;DR

Connection refused on every target means the problem is on your side of the network, not the targets'. Your tester box cannot reach the engagement network at all: the VPN is down, the egress is blocked, or the URLs carry the wrong scheme or port. Verify connectivity out of band first, then fix the path before rerunning nuclei.

[ERR] connection refused for https://target.example.com

Use this when

• Every target in scope refuses connections.
• The same URLs worked before or work from another box.
• nuclei starts fine but no request succeeds.

Not for this skill when

• One target refuses but others work. That target is down or filtered.
• Templates fail to load. That is a different failure.

Steps

1. Test connectivity outside nuclei: curl -sI https://target.example.com --max-time 10 | head -1. Verify: you see whether anything on your box can reach the target.
2. Check the engagement VPN or tunnel: ip link show and the VPN client status. Verify: the tunnel interface is up with an address.
3. Check the URL scheme and port. https on port 80 and http on port 443 both produce refusals that look like network failures. Verify: each target URL uses the scheme and port the service actually listens on.
4. Check egress filtering on your own box or network: try the same curl from a second network if you can. Verify: you know whether the block is local or upstream.
5. Only after curl succeeds, rerun nuclei against one target: nuclei -u https://target.example.com -t ~/nuclei-templates/http/technologies/. Verify: requests go out and templates execute.

Compatibility: nuclei 3.x. The connectivity checks are OS-level and version-independent.

Variant phrasings

nuclei connection refused all targets

Same fix path, common phrasing.

nuclei cannot connect target

Symptom-level search.

nuclei network unreachable engagement

The tunnel-flavored search.

Why it happens

"Connection refused" on every target is statistically a client-side problem: a dead VPN removes the route, a firewall change blocks egress, or a proxy setting intercepts the traffic. nuclei reports what the OS tells it, and the OS is telling it that nothing on your path accepts the connection.

Edge cases / pitfalls

• A proxy env var (https_proxy) can redirect nuclei traffic somewhere unexpected. Check env before blaming the network.
• Some engagements require traffic through a jump host. Confirm the routing design in the scope document.
• Do not "fix" this by scanning from an unapproved network. The engagement authorizes specific egress paths.
• Log the outage window. Targets were not actually tested during it, and the report must say so.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstkeBtkS5MLbpWXcZzv68aA