How to Find Companies Using Nginx: API Guide for 2026

Nginx is one of the most widely deployed web servers on the internet. It fronts everything from two-person SaaS products on a single VPS to the load-balancing tier of large enterprises. That ubiquity is exactly what makes a list of companies using Nginx valuable: if your product sells to teams that run their own infrastructure, “runs Nginx” is one of the cleanest buying signals you can detect from the outside.

This guide shows how to find websites using Nginx programmatically. We cover how Nginx detection actually works (and where it breaks), how to verify a single domain, how to scan an entire prospect list with batch requests, and how to read the JSON so you can separate confirmed hits from CDN-masked unknowns.

Why Build a List of Companies Using Nginx

Sales Prospecting and Technographic Targeting

Technographic data—what technology a company runs—is a stronger qualifier than firmographic data alone for many products. A company running Nginx is telling you several things at once:

• They operate their own web tier. Unlike companies on fully managed platforms, an Nginx shop has engineers who configure servers, terminate TLS, and tune proxies. If you sell observability, security tooling, deployment automation, or infrastructure services, these are your people.
• They likely run Linux infrastructure. Nginx deployments overwhelmingly sit on Linux hosts, which correlates with a whole ecosystem of tooling choices.
• They made a deliberate web-server choice. Nginx is the default in many modern stacks, but seeing it confirmed—especially as a reverse proxy in front of an application server—tells you the company has a real production architecture, not just a hosted page builder.

The same workflow applies to any detectable technology. We have written companion guides for finding companies using WordPress and finding companies using Stripe—the filter changes, the pipeline stays the same.

Security Research and Version Tracking

Security teams build Nginx inventories for a different reason: exposure management. When a CVE lands in a specific Nginx version range, the first question is “which of our domains—or our vendors’ domains—are running an affected version?” Because Nginx advertises its version in the Server header by default (Server: nginx/1.24.0), external scanning can answer that question for any site that has not disabled version tokens.

An external Nginx scan is also a quick hygiene check on your own estate: any production domain still publishing a full version string in its Server header is leaking information that most hardening guides tell you to suppress with server_tokens off.

How Nginx Is Detected (Server Headers, Error Pages, and Limits)

Nginx detection is primarily header-based. The signals, in order of reliability:

You can check any single domain manually with one command:

$ curl -sI https://nginx.org | grep -i "^server"
Server: nginx/1.27.4

The default Nginx 404 and 50x pages are another giveaway. They are short HTML documents with a centered nginx or nginx/<version> line, and they show up surprisingly often on subdomains and misconfigured vhosts even when the main site has cleaned up its headers.

When Nginx Hides Behind a CDN or Reverse Proxy

Here is the honest limitation of every external Nginx scanner: a CDN replaces the Server header with its own. When a site sits behind Cloudflare’s proxy, the edge responds with Server: cloudflare and the origin server is invisible to header inspection. The same applies to other CDN and proxy layers—you see the outermost hop, not the origin.

Practical consequences for list building:

• A domain that shows Cloudflare is not a confirmed Nginx miss—it is an unknown. The origin could be Nginx, Apache, Caddy, or anything else.
• A domain that shows Server: nginx directly is a high-confidence hit: either the company runs Nginx at its own edge, or its hosting provider does—both are real technographic signals.
• Subdomains often bypass the CDN. Companies routinely proxy www but leave api., staging., or mail. exposed, where the origin server answers directly.

If you want to understand the CDN layer itself—which edge a company chose, and how that is detected via DNS and TLS—see our guide to detecting the CDN and hosting provider of any website.

Find Companies Using Nginx with the DetectZeStack API

Manual curl -sI checks work for one domain. They do not work for a thousand. The DetectZeStack API runs the full detection pass—HTTP headers and body fingerprints, DNS records, and TLS certificates—in a single call and returns structured JSON you can filter in a script.

You can try it right now against the public demo endpoint, no API key required (it is IP-rate-limited, so use it for spot checks, not bulk scans):

$ curl -s "https://detectzestack.com/demo?url=nginx.org" \
  | jq '.technologies[] | select(.name == "Nginx")'
{
  "name": "Nginx",
  "categories": ["Web servers", "Reverse proxies"],
  "confidence": 100,
  "description": "Nginx is a web server that can also be used as a reverse proxy, load balancer, mail proxy and HTTP cache.",
  "website": "http://nginx.org/en",
  "icon": "Nginx.svg",
  "source": "http",
  "version": "1.27.4",
  "cpe": "cpe:2.3:a:f5:nginx:*:*:*:*:*:*:*:*"
}

Nginx comes back categorized as both a web server and a reverse proxy, with the version parsed out of the Server header into a structured field, and a CPE identifier you can feed into vulnerability tooling (more on that in our CPE guide for security teams).

Verify a Single Domain with /check

When all you need is a yes/no answer for one technology, the /check endpoint is the cheapest call. Pass the domain and the technology name; it returns a boolean plus confidence, version, and categories:

$ curl -s "https://detectzestack.p.rapidapi.com/check?url=example.com&tech=nginx" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com"
{
  "domain": "example.com",
  "technology": "Nginx",
  "detected": true,
  "confidence": 100,
  "version": "1.24.0",
  "categories": ["Web servers", "Reverse proxies"],
  "response_ms": 1204,
  "cached": false
}

The tech parameter is case-insensitive (nginx, Nginx, and NGINX all match), and the response echoes back the canonical technology name. detected: false means Nginx was not visible from the outside—which, per the CDN caveat above, is not always the same thing as “the company does not run Nginx.”

Scan a Prospect List with /analyze/batch

For list building, POST /analyze/batch accepts up to 10 URLs per request and analyzes them concurrently. Each entry in the response carries either a full analysis result or an error string for domains that could not be fetched:

$ curl -s -X POST "https://detectzestack.p.rapidapi.com/analyze/batch" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
  -H "Content-Type: application/json" \
  -d '{"urls": ["nginx.org", "example.com", "wordpress.org"]}'

The response shape:

{
  "results": [
    { "url": "nginx.org",     "result": { "...full analysis..." : "" } },
    { "url": "example.com",   "result": { "...full analysis..." : "" } },
    { "url": "wordpress.org", "result": { "...full analysis..." : "" } }
  ],
  "total_ms": 2341,
  "successful": 3,
  "failed": 0
}

Each result object has the same shape as a single /analyze response, so the filtering logic is identical whether you scan one domain or a thousand. For a deeper treatment of batch throughput, rate limits, and a production-ready Python scanner, see how to batch scan 1,000 websites.

Full curl Walkthrough: From Domain List to Nginx-Confirmed Leads

Here is a complete, copy-pasteable pipeline using nothing but bash, curl, and jq. It reads domains.txt (one domain per line), sends batches of 10 to /analyze/batch, and appends every Nginx-confirmed domain to nginx_leads.csv with its detected version:

#!/usr/bin/env bash
# find-nginx.sh — filter a domain list down to Nginx-confirmed leads
KEY="YOUR_KEY"
HOST="detectzestack.p.rapidapi.com"

echo "domain,nginx_version,tech_count" > nginx_leads.csv

# Process domains.txt in batches of 10 (the /analyze/batch maximum)
xargs -n 10 < domains.txt | while read -r batch; do
  urls=$(printf '%s\n' $batch | jq -R . | jq -s '{urls: .}')
  curl -s -X POST "https://$HOST/analyze/batch" \
    -H "X-RapidAPI-Key: $KEY" \
    -H "X-RapidAPI-Host: $HOST" \
    -H "Content-Type: application/json" \
    -d "$urls" |
  jq -r '.results[]
    | select(.result != null)
    | . as $r
    | $r.result.technologies[]
    | select(.name == "Nginx")
    | [$r.result.domain, .version, ($r.result.meta.tech_count | tostring)]
    | @csv' >> nginx_leads.csv
done

wc -l nginx_leads.csv

A 1,000-domain list becomes 100 batch calls. Domains that fail to resolve or time out appear in results[] with an error field instead of a result, and the select(.result != null) guard skips them cleanly.

Reading the JSON Response (confidence, version, categories)

Three fields in each technology entry matter most for an Nginx pipeline:

• confidence — reflects the detection layer that produced the match. HTTP header and body fingerprint matches score 100; DNS-based matches score 80; TLS certificate matches score 70. An Nginx hit will be a header match, so expect 100.
• version — parsed from Server: nginx/1.24.0 when present. An empty string means the site runs server_tokens off; the detection is still valid, you just do not get the version. For security workflows, a non-empty version is the actionable signal.
• categories — Nginx reports as ["Web servers", "Reverse proxies"]. The top-level categories map in the response groups every detected technology the same way, so you can grab all web-server detections with .categories["Web servers"] without iterating the array.

Also worth checking: meta.scan_depth. A value of "full" means the HTTP fetch succeeded and header detection ran. A value of "partial" means the site blocked or timed out the HTTP request and only DNS and TLS layers completed—in that case an absent Nginx entry tells you nothing, and the domain belongs in a retry queue rather than your rejects file.

Nginx vs Apache vs Caddy: What Detection Tells You About a Company

Because web servers all announce themselves the same way, the identical pipeline segments your market by server choice—just change the filter. The API detects Apache HTTP Server, Caddy, LiteSpeed, and OpenResty through the same Server-header analysis:

These profiles are heuristics, not rules, but they compound well with other signals. An OpenResty detection suggests in-house edge engineering. Caddy plus a PaaS CNAME suggests a small, modern team. Apache plus an old TLS configuration suggests legacy infrastructure—which for some products (migration tooling, security retrofits) is precisely the target market. Feeding these signals into a scoring model is covered in our lead enrichment pipeline guide.

Get Started with Your API Key

The free tier includes 100 requests per month with no credit card—enough to validate the pipeline on a sample of your prospect list before scaling up. Sign-up is instant through RapidAPI:

1. Get a key at rapidapi.com/mlugoapx/api/detectzestack.
2. Spot-check a domain you know: curl -s "https://detectzestack.p.rapidapi.com/check?url=yourdomain.com&tech=nginx" -H "X-RapidAPI-Key: YOUR_KEY" -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com"
3. Run the batch script above against your first 100 domains.

Conclusion

Finding companies that use Nginx comes down to one reliable signal—the Server header—applied at scale with honest handling of the cases where a CDN masks the origin. A single /check call answers the one-domain question; /analyze/batch turns a raw domain list into an Nginx-confirmed lead list with versions attached; and meta.scan_depth plus the confidence field tell you which negatives are real and which are unknowns worth a retry.

The same pipeline generalizes to any of the technologies in the detection database: swap the jq filter and you are segmenting by CMS, payment processor, or JavaScript framework instead of web server.