How to Find Out What Server Software a Website Runs (Nginx, Apache, LiteSpeed)

If you want to know what web server software a site runs, the fastest answer is the Server response header: run curl -I https://example.com and read the Server: line. It usually names the software directly — nginx, Apache, LiteSpeed, Microsoft-IIS or Caddy. That single header settles the question on the majority of sites. The two complications to understand are that most servers now hide their version number for security, and that a CDN or reverse proxy in front of a site often overwrites the Server header with its own value, so you see the edge rather than the origin. This guide covers how to read the header, why it is often normalised, and the secondary signals to fall back on when it is hidden.

It builds directly on how to read a website's HTTP response headers and fits into the broader how to find out what technology a website uses.

What "server software" means here

When people ask what server a site runs, they usually mean the web server software — the program that listens for HTTP requests and returns responses. The dominant players are nginx and Apache HTTP Server, which together serve a very large share of the web, followed by LiteSpeed (popular in performance-focused and WordPress hosting), Microsoft-IIS (the Windows/.NET web server), and lighter modern servers such as Caddy. This is distinct from the application framework behind the server (PHP, Node.js, Ruby) and from the hosting provider or CDN in front of it. The web server is one layer of the stack, and it is the layer the Server header is designed to describe.

Signal 1: the Server response header

The Server header is the primary fingerprint, and reading it takes one command:

curl -I https://example.com

curl -I sends a HEAD request and prints just the response headers. Look for the line that begins Server:. Common values and what they mean:

Server header value	Web server	Typical context
nginx	Nginx	Ubiquitous; modern apps, reverse proxies, many stacks
Apache	Apache HTTP Server	Traditional hosting, cPanel, lots of WordPress
LiteSpeed	LiteSpeed	Performance hosting, WordPress (LiteSpeed Cache)
Microsoft-IIS	Internet Information Services	Windows Server, ASP.NET / .NET stacks
Caddy	Caddy	Modern, automatic-HTTPS server; smaller deployments
cloudflare	(CDN, not origin)	Cloudflare proxy in front of the real server
Vercel / Netlify	(platform edge)	Frontend hosting platforms

If the value is a recognisable server name, you have your answer. If it is a CDN or platform name, that is itself useful information — it tells you an edge network is in front, which the later sections address.

Signal 2: the version number (and why it is usually hidden)

Historically the Server header included a version, like Apache/2.4.57 (Ubuntu) or nginx/1.24.0, and sometimes even the OS and loaded modules. That is valuable to an attacker, because knowing the exact version lets them look up which published vulnerabilities apply. So well-run sites deliberately suppress the version. In nginx this is the server_tokens off; directive; in Apache it is ServerTokens Prod (and ServerSignature Off for error pages); IIS and others have equivalents, and many setups strip the header at a proxy. The practical consequence: a bare Server: nginx with no version is normal, security-conscious behaviour, not a sign of anything wrong. If you do see a full version string, note it — both as a strong identification and, from a security standpoint, as mild information disclosure worth flagging in a review.

Signal 3: the CDN/proxy overwrite problem

Here is the most important caveat. When a site sits behind a CDN or reverse proxy, the response you receive comes from the edge server, which frequently replaces the origin's Server header with its own. The classic example is Server: cloudflare — that does not tell you what runs at the origin; it tells you Cloudflare is in front. The same applies to other edges. This is the same reason an IP lookup on a proxied site returns the CDN's address rather than the origin's, a point covered in how to tell if a website uses Cloudflare or another CDN. So before concluding "this site runs X," check whether a CDN is present: if the Server header names an edge network and you see CDN markers like cf-ray or a CDN Via header, you are looking at the proxy, and the origin's server software is deliberately obscured.

Signal 4: secondary tells when the header is hidden

When the Server header is bare, missing, or shows a CDN, several secondary signals can still point to the underlying server.

Default error pages. If you can trigger a 404 or a 403, the styling and wording of the default error page is distinctive: Apache's classic "Not Found / The requested URL was not found on this server" with an Apache signature, nginx's spare "404 Not Found" with an nginx footer, IIS's recognisable error layout, or LiteSpeed's branded page. Many sites customise error pages, so this only helps when the default is left in place — but when it is, it is a strong tell.

Header order and casing. Different servers emit headers in a characteristic order and with characteristic capitalisation. Nginx and Apache, for instance, have recognisable conventions for how they order and case standard headers. This is a subtle, fingerprint-style signal rather than proof, but tools and trained eyes use it to distinguish servers whose Server header has been stripped.

Platform-specific extra headers. Servers and the platforms around them often leak other headers: X-Powered-By may reveal a backend (and sometimes correlates with a server), IIS environments frequently emit X-AspNet-Version or X-AspNetMvc-Version, and LiteSpeed/WordPress stacks can surface tell-tale cache headers (X-LiteSpeed-Cache). These do not name the web server directly but narrow the possibilities considerably.

Cookie names. Session-cookie names are a quiet giveaway: a PHPSESSID cookie points to PHP (commonly Apache or LiteSpeed), an ASP.NET_SessionId points to an IIS/.NET stack, a JSESSIONID to a Java application server. The cookie names the runtime rather than the web server precisely, but it constrains the answer.

Method 1: curl -I from the terminal

The cleanest method is the terminal. curl -sI https://example.com prints the response headers (the -s suppresses curl's progress meter). Read the Server line first, then scan for the secondary headers above (X-Powered-By, X-AspNet-Version, cache headers) and any Set-Cookie names. Because curl is scriptable, you can run the same check across many URLs at once — handy for surveying a list of sites. If a site redirects (a 301/302 on the bare domain to the https://www version), add -L to follow it (curl -sIL) so you read the final response's headers rather than the redirect's, a nuance explained in the HTTP headers guide.

Method 2: the DevTools Network tab

In a browser, open DevTools (F12), go to the Network tab, reload the page, and click the main document request (usually the first one). The Response Headers panel shows the Server header and everything else the server sent. This is the most visual method and has a bonus: you can click individual resources — an image, a CSS file, a static asset — and see whether they carry a different Server header. That happens when static assets are served from a different server or CDN than the HTML, which reveals a split architecture you would miss by checking only the document.

Method 3: detection tools and online checkers

Tools fold the server identification into a broader report. Wappalyzer and BuiltWith list the detected web server alongside the rest of the stack, applying their own fingerprint rules (including some of the header-order and secondary-signal logic above). Online "what's my server" header-checkers let you paste a URL and read its Server header without a terminal — convenient, though they fetch from their own location, which can matter when responses vary by region. Broader audits, StackOptic among them, identify the server as one element of a full technology, hosting and security report, so you see it in context rather than as an isolated string.

A worked example

You want to know what powers a prospect's site. You run curl -sI https://www.example.com and read the headers. The Server line says Apache — no version, which is normal. You also spot X-Powered-By: PHP/8.1 and a Set-Cookie: PHPSESSID=.... The picture is consistent: an Apache web server running a PHP application, the textbook profile of traditional or WordPress-style hosting. To double-check there is no CDN masking things, you note the absence of cf-ray or a CDN Via header, so this looks like the real origin rather than an edge. For contrast, a second site returns Server: cloudflare with a cf-ray header and no backend tells — there, Cloudflare is in front and the origin server is hidden, so you record "Cloudflare edge; origin server not disclosed" rather than guessing. Two commands, two clear and honestly-bounded reads.

What the web server tells you about a site

The server software is a meaningful clue about a site's broader setup. nginx is the workhorse of the modern web and fronts an enormous variety of stacks, so on its own it is less distinguishing — but it often signals a deliberately configured, performance-minded deployment or a reverse proxy in front of an app. Apache remains extremely common in traditional shared hosting, cPanel environments and a large share of WordPress sites. LiteSpeed specifically signals performance-oriented hosting and frequently a WordPress site using LiteSpeed Cache. Microsoft-IIS is a clear flag for a Windows Server and .NET environment, which tells you a lot about the rest of the stack. And Caddy suggests a modern, smaller-scale deployment that values automatic HTTPS and simple configuration. Combined with the hosting provider and the application signals, the web server helps you place a site's engineering choices — useful for hosting detection, competitive research and security assessment alike.

How reliable is server-software detection?

Reliable when the Server header is present and names a real server, and reasonably reliable through secondary signals when it is not. The two honest limits are the ones stressed throughout: a CDN/proxy can replace the header so you see the edge rather than the origin, and operators can strip or fake the header entirely. So "what does the edge report?" is almost always answerable, while "what runs at the origin behind this CDN?" is sometimes deliberately unanswerable from outside. The right posture is to read the Server header, check for a CDN before trusting it as the origin, and corroborate with error pages, header order, extra headers and cookie names. When those agree, state the server with confidence; when a CDN masks the origin, say so plainly rather than guessing.

The workflow

1. Run curl -sI https://example.com and read the Server header first.
2. Check whether a CDN is in front (cf-ray, CDN Via, an edge name in Server) before treating the value as the origin.
3. Note the version if present — it both identifies and, for security, flags disclosure.
4. Fall back to secondary signals when the header is hidden: error pages, header order, X-AspNet-Version, cache headers, cookie names.
5. Corroborate and report honestly — name the server when signals agree; say "origin hidden behind CDN" when they do not.

Go deeper

• The header reference: how to read a website's HTTP response headers.
• The CDN in front: how to tell if a website uses Cloudflare or another CDN.
• Where it all lives: how to find out where a website is hosted.
• The whole stack: how to find out what technology a website uses.

Want the web server, hosting, CDN and full stack identified automatically? Analyse any site with StackOptic — one report, free, no sign-up.