Debugging `httpx` in the ProjectDiscovery stack: binary conflicts, go modules, and PATH

While setting up a standard reconnaissance pipeline (subfinder + httpx + nuclei), what seemed like a routine configuration turned into a practical lesson in operating system fundamentals: binary name collisions, PATH priority, and internal shell hashing.

This article documents exactly what broke, how I verified the root cause, and the operational baseline I implemented to prevent similar incidents in production environments.

1) Target pipeline#

The intended workflow was a linear chain for domain enumeration and vulnerability scanning:

subfinder -d domain.com -silent | httpx -silent -status-code -title -tech-detect | nuclei -severity critical,high

2) A "ghost" flag error#

Upon execution, the terminal returned the following error:

Usage: httpx [OPTIONS] URL
Error: No such option: -s

The anomaly here was that I didn't use -s; I used the full -silent flag. When a tool complains about a flag you didn't explicitly type, it almost certainly means you are executing the wrong program with the right name.

3) Forensic diagnosis: binary collision#

To isolate exactly which file was being called, I used the type -a command:

type -a httpx

The diagnostic confirmed a name collision on the host:

1. /usr/bin/httpx: A Python-based HTTP client library installed via apt or pip.
2. /root/go/bin/httpx: The official Go-based binary from ProjectDiscovery.

The shell was resolving to /usr/bin/httpx first, causing all ProjectDiscovery-specific syntax and flags to fail.

4) Why go install isn't enough (PATH precedence)#

Even after running the correct installation command:

go install github.com/projectdiscovery/httpx/cmd/httpx@latest

The terminal continued to trigger the Python version. This occurred because the shell's $PATH prioritized /usr/bin over the $GOPATH/bin directory.

Applied correction#

To resolve this on the recon host and ensure stability:

# Remove the conflicting binary (if not required for other tasks)
rm -f /usr/bin/httpx /bin/httpx

# Sanitize the official binary to a predictable, high-priority location
cp "$(go env GOPATH)"/bin/httpx /usr/local/bin/httpx
chmod +x /usr/local/bin/httpx

After these steps, type -a httpx correctly pointed to /usr/local/bin/httpx as the primary executable.

5) The shell hash cache: the "ghost" post-fix failure#

Even after removing the conflicting /usr/bin/httpx binary, the Bash shell continued to fail with:

-bash: /usr/bin/httpx: No such file or directory

The cause is the internal shell hash table. To optimize performance, Bash caches the absolute paths of recently executed commands. Even if the file is moved or deleted, the shell will attempt to use the cached path until the table is cleared.

Immediate Fix:

hash -r

Without this command, you can correctly fix the underlying system only to be stymied by a stale path in the shell's memory.

6) Versioning and go modules: the /v3 myth#

During troubleshooting, I observed attempts to install httpx/v3 based on generic Go module patterns. However, at the time of this analysis, the official ProjectDiscovery httpx was in the v1.x branch (e.g., v1.7.4).

Forcing a major version suffix like /v3 in go install when the module doesn't explicitly support it will break the build process.

Best Practice:

• Always confirm the latest official repository tags.
• Only append major version suffixes (like /v2, /v3) when the module's documentation specifically instructs to do so.

7) ProjectDiscovery stack hardening baseline#

I have added this checklist to my operational playbook for all reconnaissance nodes:

1. Verify Binary Resolution: Always use type -a [tool] rather than just which.
2. Version Validation:

   httpx -version

1. Shell Integrity: Run hash -r after any tool update or path manipulation.
2. Standardization: Prefer /usr/local/bin for team-shared operational binaries.
3. Tool Management: Evaluate pdtm (ProjectDiscovery Tool Manager) for standardized updates across the suite.

8) Final pipeline validation#

After the environment cleanup:

subfinder -d domain.com -silent | httpx -silent -status-code -title -tech-detect | nuclei -severity critical,high

The pipeline returned consistent results, successfully handing off enumerated subdomains to the HTTP probing layer without flag errors.

Technical conclusion#

The issue was not a software bug within httpx. It was a failure of name resolution within Linux caused by a binary collision. By treating $PATH precedence, shell cache management, and binary governance as critical infrastructure components, reconnaissance workflows become robust and reproducible rather than erratic.

See also

Infrastructure Linux troubleshooting: when 'command not found' made me revisit PATH and sudo su

Cybersecurity Incident anatomy: mitigating simultaneous L7 attacks, Dovecot DoS, and CPU bottlenecks

Cybersecurity Forensic analysis of a CloudLinux and cPanel compromise: from the sshd_config trap to PAM and IPMI persistence

This post is licensed under CC BY-NC.