A web server is software, and by extension the hardware it runs on, that receives HTTP and HTTPS requests from clients and returns appropriate responses. When a browser navigates to a URL the browser sends an HTTP request to the web server at the address specified by the URL. The web server receives the request, processes it according to its configuration, and returns an HTTP response, which may be the content of a file, a dynamically generated page, a redirect response, an error response, or any other valid HTTP response.

Web servers are the fundamental serving infrastructure of the web, every web page, API response, file download, and redirect response is ultimately delivered by a web server. The web server is the component that listens on network ports, typically port 80 for HTTP and port 443 for HTTPS, accepts incoming TCP connections from browsers and other clients, reads HTTP request data, applies configured rules and logic, and writes HTTP response data back to the client.

The term web server refers both to the software, Nginx, Apache, Caddy, IIS, and to the physical or virtual machine running that software. In common usage the distinction is often implicit, saying a web server handles a redirect means the web server software on the origin server processes the redirect rule and returns a redirect response. Understanding the distinction matters when discussing architecture, multiple web server software instances running on multiple machines can collectively constitute a web server in the broader sense.

Web servers are the layer at which many redirect rules are implemented, Nginx and Apache redirect directives execute in the web server layer before requests reach application code. Understanding how web servers work, what they can do natively, how they are configured, and how they interact with other infrastructure, is foundational to understanding redirect management at the infrastructure level.

What web servers do

Web servers perform several distinct functions, some fundamental to all web servers and others provided as optional or configurable features.

Request reception and connection management: the most basic web server function. The web server listens on configured network ports, binding to IP addresses and port numbers, and accepts incoming TCP connections from clients. Modern web servers manage thousands of simultaneous connections using event-driven, non-blocking I/O, accepting new connections without waiting for existing connections to complete. Connection management includes TLS handshake processing for HTTPS connections, though SSL termination is sometimes offloaded to a reverse proxy or load balancer in front of the web server.

Static file serving: serving files directly from the filesystem. A request for https://example.com/images/logo.png maps to a file at a configured path on the server’s filesystem, the web server reads the file and returns its contents as the HTTP response. Static file serving is extremely fast, the web server reads from disk or OS cache and writes to the network socket with minimal processing. Modern web servers are highly optimised for static file serving, Nginx in particular is designed around efficient static file delivery.

Dynamic content proxying: forwarding requests to application servers, Node.js, Python, PHP, Ruby, Java, that generate dynamic responses. The web server acts as a reverse proxy between the client and the application server, receiving the client request, forwarding it to the application, receiving the application’s response, and returning it to the client. This proxying architecture keeps the application server isolated from direct internet exposure and allows the web server to handle static files directly while passing dynamic requests to the application.

Request routing: directing incoming requests to different backends or returning different responses based on request attributes. The Host header routes requests to different virtual hosts, websites, on the same server. The URL path routes requests to different backends, /api/* requests to an API server, /static/* requests to a file server. Request routing is configured through virtual host configuration, location blocks, Nginx, or virtual host containers, Apache.

Redirect processing: returning redirect responses for requests matching configured redirect rules. Web server redirect rules are a native capability, Nginx’s return and rewrite directives, Apache’s Redirect and RewriteRule directives. Redirect rules at the web server layer execute before requests reach application code, fast and efficient for simple static redirects.

Logging: recording details of every request and response. Access logs record the client IP address, request method, URL, status code, response size, and other attributes. Error logs record server errors, configuration issues, and diagnostic information. Log data is essential for monitoring, debugging, security analysis, and understanding redirect traffic patterns.

Major web server software

Several web server implementations dominate web infrastructure, each with different design philosophies, performance characteristics, and appropriate use cases.

Nginx, pronounced engine-x: the most widely deployed web server on the internet, particularly for high-traffic sites. Nginx was designed from the ground up for high-concurrency performance, its event-driven, asynchronous architecture handles thousands of simultaneous connections with minimal memory usage. Where Apache uses a thread-per-connection model, spawning a new thread for each connection, Nginx uses a small fixed number of worker processes that each handle thousands of connections through non-blocking I/O.

Nginx excels at static file serving, reverse proxying, and load balancing. Its configuration language is concise and expressive, redirect rules are simple one-liners. Nginx is the dominant choice for high-traffic production web servers and as a reverse proxy in front of application servers.

Nginx redirect example, permanent redirect from HTTP to HTTPS:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https

Apache HTTP Server: the web server that powered the early commercial internet. Apache uses a modular architecture, functionality is added through modules like mod_rewrite for URL rewriting, mod_ssl for HTTPS, and mod_proxy for reverse proxying. Apache’s .htaccess files, per-directory configuration files, allow site owners to configure redirects and rewriting without access to the main server configuration. This decentralised configuration capability made Apache the dominant choice for shared hosting environments.

Apache’s mod_rewrite module provides powerful and flexible URL rewriting and redirect rules through regular expressions. The complexity of mod_rewrite configuration has spawned extensive documentation and tooling, many hosting platforms provide mod_rewrite-based redirect management through control panels.

Apache redirect example, using.htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Caddy: a modern web server with automatic HTTPS as a defining feature. Caddy automatically obtains and renews SSL certificates from Let’s Encrypt for all configured domains, no certificate management required. Caddy’s Caddyfile configuration syntax is simpler and more readable than Nginx or Apache configuration. Caddy supports HTTP/2 and HTTP/3 out of the box without additional configuration.

Caddy’s automatic HTTPS is particularly relevant for redirect management, redirect source domains connected to a Caddy-based server automatically receive SSL certificates, enabling HTTPS redirect serving without manual certificate provisioning.

Caddy redirect example:

example.com {
    redir https://new-domain.com{uri} 301
}

example.com {
    redir https://new-domain.com{uri} 301
}

example.com {
    redir https://new-domain.com{uri} 301
}

Microsoft IIS, Internet Information Services: Windows-native web server integrated with the Windows Server operating system. IIS is the primary web server for ASP.NET applications and Windows-based hosting environments. IIS uses XML-based configuration files and provides a graphical management interface through IIS Manager. IIS supports URL rewriting through the URL Rewrite module, providing capabilities similar to Apache mod_rewrite for Windows-based hosting.

LiteSpeed: a commercial web server compatible with Apache configuration syntax, including.htaccess files, but with better performance characteristics than Apache for high-traffic scenarios. LiteSpeed’s compatibility with Apache configuration makes it a drop-in replacement for many Apache deployments. LiteSpeed Enterprise is widely used by web hosting providers as a performance improvement over Apache.

Node.js HTTP servers: Node.js applications frequently include their own HTTP server, the built-in http and https modules serve requests directly without a separate web server. In production Node.js applications typically run behind an Nginx or Apache reverse proxy, the proxy handles static files, SSL termination, and redirect rules while Node.js handles dynamic application logic.

Web server configuration for redirects

Web server redirect configuration varies by implementation, each major web server has its own syntax and capabilities for defining redirect rules.

Nginx redirect directives: Nginx provides return and rewrite directives for redirect configuration. The return directive is preferred for simple redirects, it is more efficient than rewrite because it short-circuits further processing.

# Simple 301 redirect
location /old-page {
    return 301 /new-page;
}

# Domain redirect preserving path
server {
    server_name old-domain.com;
    return 301 https://new-domain.com$request_uri;
}

# Regex-based redirect with rewrite
rewrite ^/blog/(\d{4})/(\d{2})/(.+)$ /blog/$3 permanent

# Simple 301 redirect
location /old-page {
    return 301 /new-page;
}

# Domain redirect preserving path
server {
    server_name old-domain.com;
    return 301 https://new-domain.com$request_uri;
}

# Regex-based redirect with rewrite
rewrite ^/blog/(\d{4})/(\d{2})/(.+)$ /blog/$3 permanent

# Simple 301 redirect
location /old-page {
    return 301 /new-page;
}

# Domain redirect preserving path
server {
    server_name old-domain.com;
    return 301 https://new-domain.com$request_uri;
}

# Regex-based redirect with rewrite
rewrite ^/blog/(\d{4})/(\d{2})/(.+)$ /blog/$3 permanent

The permanent flag in the rewrite directive produces a 301 response. The redirect flag produces a 302.

Apache mod_rewrite: Apache’s URL rewriting module provides comprehensive redirect capabilities through RewriteRule directives with regular expression matching.

# Redirect with condition
RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]

# Remove trailing slash
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [R=301,L]

# Redirect with condition
RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]

# Remove trailing slash
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [R=301,L]

# Redirect with condition
RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]

# Remove trailing slash
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [R=301,L]

The [R=301,L] flags specify a 301 redirect, R for redirect, the number for the status code, and L to stop processing further rules after this one matches.

Virtual hosts and server blocks: both Nginx and Apache use virtual host configurations, server blocks in Nginx, VirtualHost containers in Apache, to define configuration for specific domains. Redirect domains, domains that should redirect all traffic to a destination, have dedicated virtual host configurations that return redirect responses for all requests.

Web server performance and redirects

Web server performance directly affects redirect response latency, how quickly users receive the redirect response and begin loading the destination.

Time to first byte for redirects: the time between a browser sending a redirect request and receiving the redirect response, is determined by the web server’s processing speed and the network latency between the browser and the server. Web server redirect processing is extremely fast, Nginx redirect rules execute in microseconds. The dominant factor in redirect response time is network latency, the time for the request to travel from the browser to the server and the response to travel back.

Edge-based vs origin-based redirect serving: web server redirects configured at the origin server require requests to travel from the browser to the origin, potentially a long distance. Redirect management platforms built on CDN and edge network infrastructure serve redirects from edge nodes near users, reducing the network latency component of redirect response time from hundreds of milliseconds to tens of milliseconds.

HTTP/2 and HTTP/3 for redirect efficiency: web servers supporting HTTP/2 and HTTP/3 serve redirect responses with lower overhead than HTTP/1.1, connection multiplexing, header compression, and faster connection establishment all reduce the total time for a redirect sequence. Modern web servers, Nginx, Caddy, support HTTP/2 and HTTP/3 natively.

Web server security and redirects

Web server security configuration affects redirect management, particularly for HTTPS enforcement and HSTS deployment.

Forced HTTPS at the web server: the universal redirect pattern in modern web server configuration. Every HTTP request, port 80, is redirected to HTTPS, port 443. The web server configuration dedicates the HTTP virtual host exclusively to this redirect, no content is served over HTTP.

HSTS headers at the web server: web servers add HSTS headers to HTTPS responses, instructing browsers to always use HTTPS for the domain without going through the HTTP-to-HTTPS redirect. The web server configuration adds the Strict-Transport-Security header to all HTTPS responses, progressively increasing the max-age as confidence in the HTTPS configuration grows.

Security headers in redirect responses: redirect responses should include appropriate security headers, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, even though the browser will follow the redirect immediately. Headers on redirect responses apply to the redirect itself, though browsers may not fully process all security headers on redirect responses before following to the destination.