Three tools took the scan's network config and dropped part of it.
The banner prober spoke SOCKS5 to whatever proxy it was given. A scan
context holding an http:// proxy made every handshake fail, and the stage
reported "no banner returned by N ports" rather than a problem. It now
speaks SOCKS5 or HTTP CONNECT by scheme (tools/banner/proxy.py, tested
against a stub proxy), and refuses a scheme it cannot carry before any
port is touched instead of dialling direct.
naabu was handed the resolved URL whole. Its -proxy is socks5 only and
takes no inline credentials, so http:// or any password quietly did not
apply. proxy_args() renders -proxy host:port with -proxy-auth beside it,
and names the reason when the proxy cannot be expressed, which port_scan
and host_discovery report as partial. -passive is an HTTPS call to
Shodan, so it goes through proxy_env instead, which passive_ports was not
passing at all.
wafw00f got the proxy but never the headers, so an authenticated surface
was fingerprinted unauthenticated. It takes a file rather than a value,
so the run writes one 0600 temp file and removes it after.
proxy_env moves to shared/services/proxy_resolve.py now that naabu wants
it too, and host_port() lands in shared/utils/net.py for the bracketed
IPv6 authority CONNECT needs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X5roHYDYzSPRNaTkn8hSkJ