A web server works by receiving HTTP requests from browsers and other clients, determining which resources or services those requests refer to, and sending back HTTP responses. It can deliver existing files, such as HTML documents and images, or forward requests to application software that generates content dynamically.
For example, when you open a website, a web server may receive a request for its homepage, locate the appropriate content, and return an HTML document. Your browser then interprets that document and requests any additional resources needed to display the page.
Modern web servers also handle secure connections, route requests to different applications, manage multiple connections, and control how responses are cached or delivered.
Their fundamental responsibility remains the same: accept a web request and produce or obtain the appropriate response.
What Is a Web Server?
A web server is a computer system or software application that provides web resources to clients using HTTP.
The term has two related meanings.
Web server hardware refers to the physical or virtual computing infrastructure on which server software runs.
Web server software refers to the program that accepts HTTP requests and provides responses.
Examples of web server software include NGINX, Apache HTTP Server, and Microsoft Internet Information Services (IIS).
According to MDN’s explanation of web servers, an HTTP server understands web addresses and the HTTP protocol and can deliver resources requested by browsers.
A web server may provide:
- HTML documents.
- CSS stylesheets.
- JavaScript files.
- Images and fonts.
- Video and downloadable files.
- Data generated by web applications.
- Responses from other servers or backend services.
A server does not need to store every resource on its own local disk.
Depending on its configuration, it may retrieve content from another system, forward requests to an application, or serve previously cached responses.
This distinction is important because modern websites commonly use several cooperating services instead of one computer performing every operation.
How Does a Web Server Work Step by Step?
Consider a visitor opening this example webpage:
https://www.example.com/products
The following process describes a common web server architecture.
Step 1: The Browser Locates the Website
The visitor enters the address into a web browser.
The browser identifies the requested hostname:
www.example.com
It also identifies the /products path and the HTTPS scheme.
The hostname is part of the website’s domain name structure.
The browser uses the Domain Name System (DNS) to obtain suitable network addressing information if that information is not already available.
For example, DNS may return an IP address associated with the website’s hosting infrastructure or a reverse proxy.
The browser can then establish communication with the selected destination.
The web server does not necessarily participate in this DNS lookup. DNS typically operates as a separate service.
Step 2: The Server Accepts a Connection
A web server normally listens for incoming connections on one or more configured network interfaces and ports.
For conventional web communication, the familiar default ports are:
| Connection Type | Conventional Default Port |
|---|---|
| HTTP | TCP port 80 |
| HTTPS using HTTP/1.1 or HTTP/2 | TCP port 443 |
| HTTPS using HTTP/3 | UDP port 443, commonly |
These are defaults, not mandatory port numbers for every deployment.
When a client connects, the server’s operating system and networking software handle the appropriate transport-level communication.
For HTTP/1.1 and HTTP/2, this commonly involves TCP.
For HTTP/3, communication uses QUIC over UDP.
The server software then processes the incoming HTTP exchange using the protocol version it supports.
Step 3: HTTPS Establishes a Secure Connection
Most public websites use HTTPS.
With HTTPS, TLS protects the communication between the browser and the endpoint terminating the secure connection.
For HTTPS over TCP, the client and server negotiate a TLS connection, establish cryptographic keys, and authenticate the server using its certificate.
For HTTP/3, TLS security is integrated into QUIC’s handshake.
However, the server handling the application’s HTTP request is not always the same system that terminates the visitor’s TLS connection.
A CDN, load balancer, or reverse proxy may terminate TLS at the network edge and forward the request to another server.
The backend connection may have its own encryption and authentication configuration.
HTTPS therefore protects communication between the relevant TLS endpoints, not automatically every connection between every server involved in processing a website.
Step 4: The Web Server Receives the HTTP Request
Once the required communication is established, the client sends an HTTP request.
A simplified HTTP/1.1 example looks like this:
GET /products HTTP/1.1
Host: www.example.com
Accept: text/htmlThe request contains information that helps the server determine what the client wants.
GET identifies the HTTP method.
/products identifies the target resource.
Host identifies the requested hostname.
Accept indicates which types of response content the client can accept.
The server parses the request according to the applicable protocol rules.
For HTTP/2 and HTTP/3, requests use different wire representations, including pseudo-header fields, but preserve comparable HTTP semantics.
The protocol itself is explained in How Does HTTP Work?.
Step 5: The Server Determines Which Website Should Handle the Request
One web server can host multiple websites.
For example, the same server might handle:
www.example.com
blog.example.com
shop.example.net
The server uses its configuration and the request’s authority or hostname information to determine the appropriate website or application.
This mechanism is called virtual hosting.
In HTTP/1.1, the Host header identifies the requested authority.
HTTP/2 and HTTP/3 use the :authority pseudo-header for this purpose in typical requests.
For HTTPS, TLS information such as Server Name Indication (SNI) can also help an endpoint select the appropriate certificate during connection establishment.
According to the Apache HTTP Server documentation on name-based virtual hosting, different hostnames can share the same IP address while being served through different virtual host configurations.
After identifying the appropriate website, the web server applies its configured request-handling rules.
Step 6: The Server Chooses How to Handle the Resource
A web server does not necessarily treat every URL as a filename.
It uses routing and configuration rules to decide how to process the request.
For example:
| Requested Path | Illustrative Handling |
|---|---|
/images/logo.png | Return a static image |
/styles/main.css | Return a stylesheet |
/products | Forward to a backend application |
/api/search | Route to an API service |
/old-page | Send an HTTP redirect |
These examples are hypothetical. Actual behavior depends on the server’s configuration.
A request may be handled through a file lookup, an internal redirect, a reverse proxy, an application handler, or another supported mechanism.
The NGINX Beginner’s Guide demonstrates how server configuration can direct requests to static files, proxy destinations, and application-processing interfaces.
This selection is a defining part of web server operation.
Step 7: The Server Retrieves or Generates Content
Suppose /products belongs to an online store.
The requested page could be handled in several ways.
Static handling: The server retrieves a prebuilt HTML document and prepares it for delivery.
Dynamic handling: The server forwards the request to an application that retrieves product information and generates a suitable response.
For a dynamic request, the application may need to contact a database or another service.
For example, it might retrieve product names, prices, and availability.
The web server may act as the entry point, while separate software performs the business logic.
This is why web servers and application servers are related but distinct concepts.
The MDN introduction to server-side programming explains how dynamic websites can generate content using application logic and stored information.
Step 8: The Server Constructs an HTTP Response
After retrieving the content or receiving the backend’s result, the web server sends an appropriate HTTP response.
For a successful HTML request using HTTP/1.1, a simplified response might look like this:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
<!doctype html>
<html lang="en">
<head>
<title>Products</title>
</head>
<body>
<h1>Our Products</h1>
</body>
</html>This example contains several components.
200 OK indicates that the request succeeded.
Content-Type tells the client that the response contains HTML encoded using UTF-8.
Cache-Control provides caching instructions.
Response body contains the HTML document.
The no-cache directive allows storage under applicable rules but requires successful validation before reuse. It does not mean that caching is completely prohibited.
The server may also send other headers relating to security, content encoding, cookies, redirects, and validation.
Not every HTTP response contains a body.
For example, a 204 No Content response has no response content, and a 304 Not Modified response allows a client to reuse an appropriate cached representation.
Step 9: The Browser Receives and Displays the Page
The response travels back to the client.
If the result is an HTML document, the browser begins interpreting it.
The browser may then make additional requests for images, stylesheets, scripts, fonts, and other resources.
The web server handles those requests individually or through suitable multiplexed connections.
The browser parses HTML, processes CSS, executes relevant JavaScript, calculates layout, and renders the page.
This work takes place on the client side.
The server provides the content and response information, but it generally does not determine the exact pixels displayed on the visitor’s screen.
The full relationship between browser, frontend, backend, and storage is explained in How Does a Website Work?.
How Does a Web Server Serve Static Files?
Static file serving is one of the simplest web server functions.
A static resource exists in a form that can be returned without generating new application content for each request.
Examples include:
- HTML files.
- CSS stylesheets.
- JavaScript bundles.
- Images.
- Fonts.
- PDF documents.
Suppose the browser requests:
https://www.example.com/images/logo.png
The server configuration may map this URL to a file in a designated content directory.
The server checks whether it is permitted to serve that resource.
If the file exists and is accessible, it can prepare an HTTP response containing the image.
The response may include:
Content-Type: image/png
The browser uses this media type to interpret the returned content appropriately.
Does a URL Always Match a Physical File?
No.
Some servers map URL paths to files, but others use rewrite rules, application routes, or storage services.
For example, a URL such as:
/articles/how-servers-work
might correspond to a dynamically generated article rather than a file with that name.
The server’s configuration and application determine the mapping.
A secure server must also avoid treating arbitrary client-supplied paths as unrestricted access to its filesystem.
Only intended resources should be made accessible.
How Does a Dynamic Web Server Work?
A dynamic web server setup allows responses to be generated using application logic, stored data, or information from the incoming request.
Consider an online store that receives:
GET /products/1042
The request might follow this simplified path:
Browser → Web Server → Application Server → Database
The application receives the product identifier and retrieves the relevant information.
It might generate a response containing:
- Product name.
- Current price.
- Available inventory.
- Product description.
- Related products.
The result can be returned as HTML or structured data such as JSON.
The web server then sends the HTTP response to the client.
However, not every dynamic request requires a database query.
Applications can also use caches, local computation, external APIs, or other data sources.
Can a Web Server Generate Dynamic Content by Itself?
Yes, depending on the software and architecture.
The distinction between a web server and an application server is functional, not always a boundary between two separate physical machines.
Some software stacks integrate HTTP request handling and application execution in one process.
Others use dedicated frontend web servers that communicate with separate application processes.
For example, NGINX can forward requests to backend services, while an application framework may provide its own HTTP server.
Both architectures can support dynamic websites.
What Is the Difference Between a Web Server and an Application Server?
A web server’s core responsibility is handling HTTP communication and delivering or routing resources.
An application server executes application-specific logic.
| Feature | Web Server | Application Server |
|---|---|---|
| Primary responsibility | Handle web requests and responses | Execute application logic |
| Static files | Commonly serves them directly | May serve them |
| Dynamic processing | May forward or perform it | Common responsibility |
| Database operations | Not required for basic operation | Often performed through application code |
| Examples | NGINX, Apache HTTP Server, IIS | Application runtimes and servers for Node.js, Java, Python, or other platforms |
A typical architecture might use NGINX as a reverse proxy in front of a Python application.
NGINX receives the incoming request.
It may serve static resources directly or forward an application request to the Python service.
The application performs its work and sends the result back.
However, a Node.js application can also expose an HTTP endpoint directly without placing NGINX in front of it.
A separate frontend web server is common, but not mandatory.
The important question is which software handles the networking interface and which software performs the application logic.
How Does a Web Server Handle Multiple Websites?
Modern web servers can serve different websites through the same network address.
This is called virtual hosting.
For example, a single server with a suitable configuration might serve:
www.example.comnews.example.comwww.example.net
Each hostname can have its own document directory, backend application, logging rules, and security settings.
The server uses the network connection details and requested hostname to select the appropriate configuration.
For HTTPS, the endpoint must also select a suitable certificate covering the requested hostname.
A web server can therefore host several independent websites without assigning one physical machine to each domain.
A single website can also use several servers.
Virtual hosting and distributing one site across multiple servers are different architectural choices.
How Does a Reverse Proxy Work with a Web Server?
A reverse proxy accepts requests from clients and forwards them to backend servers when needed.
It sits between the client and the application infrastructure.
For example:
Browser → Reverse Proxy → Application Server
The reverse proxy receives a request and applies its configured routing rules.
It may forward the request to a particular backend service, wait for the response, and send that response to the visitor.
According to NGINX’s reverse proxy documentation, reverse proxies can forward requests to HTTP servers and other supported application interfaces.
They can also modify forwarding headers and buffer responses.
A reverse proxy can help with tasks such as:
- Directing requests to different backend applications.
- Terminating HTTPS connections.
- Caching eligible responses.
- Restricting unwanted traffic.
- Applying request-size or rate limits.
- Managing upstream connection behavior.
These functions depend on configuration rather than being universally active on every reverse proxy.
The difference between forward and reverse proxies is covered in How Does a Proxy Server Work?.
How Does a Web Server Handle Thousands of Connections?
A busy web server may need to communicate with many clients at the same time.
It cannot practically require every visitor to wait until all earlier visitors have finished downloading their pages.
Web server software therefore uses concurrency techniques to manage connections and process requests.
Different implementations use different designs.
Processes and Threads
Some web servers use multiple operating-system processes or threads.
These units of execution allow work to proceed concurrently.
For example, one worker may handle a request while another worker processes a different connection.
This approach can be effective, but every process or thread consumes computing resources.
Event-Driven Processing
Other systems use event-driven architectures.
Instead of assigning a dedicated thread to every connection, an event loop can monitor many connections and respond when they are ready for work.
NGINX is a well-known example of a web server using event-driven worker processes.
Its official Beginner’s Guide describes how worker processes use operating-system mechanisms to process requests efficiently.
Event-driven systems can reduce some connection-management overhead.
However, event-driven architecture alone does not guarantee that every workload performs well.
If a worker performs expensive blocking operations, responsiveness can still suffer.
What Limits Concurrent Requests?
A web server’s practical capacity depends on several factors:
- CPU and memory resources.
- Available network bandwidth.
- Connection and file descriptor limits.
- Response sizes.
- TLS processing requirements.
- Backend application capacity.
- Storage and database performance.
- Request complexity and server configuration.
A server capable of maintaining many idle connections may support fewer simultaneous computationally expensive requests.
Therefore, the number of open connections and the number of requests successfully processed per second are different measurements.
How Does a Load Balancer Work with Web Servers?
A single server has finite capacity.
To handle more traffic or improve availability, a website can operate multiple server instances.
A load balancer distributes incoming connections or requests among suitable backend servers.
For example:
Client → Load Balancer → Web Server A, B, or C
The load balancer may select a server using algorithms such as round robin, least connections, or other supported policies.
It can also monitor backend health and avoid sending eligible traffic to an instance that is known to be unavailable.
This helps distribute demand and can improve resilience.
However, load balancing does not automatically fix an overloaded database or another shared dependency.
If every application server depends on one unavailable database, adding more frontend servers may not restore the website.
How Does Web Server Caching Work?
Web servers can support caching by instructing clients and intermediaries when responses may be reused.
Some web servers also maintain their own caches of upstream responses.
Caching reduces repeated work when the same content is requested multiple times.
Browser and Shared Caching
Consider a stylesheet returned with:
Cache-Control: public, max-age=3600
The header allows the response to be stored in shared caches under applicable rules and indicates a freshness lifetime of 3,600 seconds.
A browser can reuse a fresh cached response without downloading it again.
When the response becomes stale, the client may need to validate it.
For example, the server can provide an ETag, and the client can later send an If-None-Match request header.
If the representation has not changed, the server can respond:
304 Not Modified
The cached content can then be reused.
MDN’s HTTP caching documentation explains how freshness and conditional requests reduce unnecessary resource transfers.
Server-Side Caching
Server-side caching can also avoid repeating expensive operations.
For example, an application may cache a product listing rather than querying its database for every identical request.
A reverse proxy may cache eligible upstream HTTP responses.
However, caching requires care when content is personalized.
An incorrectly configured shared cache can expose one user’s private response to another user.
Caching rules must account for authentication, cookies, response variations, and the application’s data requirements.
How Does a CDN Differ from a Web Server Cache?
A content delivery network (CDN) distributes content-delivery infrastructure across multiple locations.
An origin web server may be responsible for generating or storing original content, while CDN edge servers deliver eligible cached responses to visitors.
For a cache hit, the CDN may answer the request without contacting the origin.
For a miss, it may need to retrieve the content upstream.
The two systems can work together, but not every request reaches the origin web server.
How Does a Web Server Use HTTPS?
A web server or an associated network component can terminate TLS connections for HTTPS traffic.
This requires suitable certificate configuration and support for the relevant TLS protocol.
When the endpoint receives an encrypted request, the TLS implementation authenticates and decrypts the protected application data.
The HTTP server can then process the request.
It encrypts the outgoing response through the established secure connection.
In architectures using reverse proxies or CDNs, the public-facing TLS endpoint may be separate from the origin web server.
The operator should ensure that any required upstream connections are also appropriately protected.
Does HTTPS Automatically Secure the Server?
No.
HTTPS protects communication between TLS endpoints.
It does not prevent unauthorized access caused by weak passwords, vulnerable applications, exposed administration interfaces, or incorrect permissions.
Web server security requires multiple controls, including appropriate software updates, access restrictions, and secure application configuration.
How Does a Web Server Protect Itself from Attacks?
A web server is exposed to requests from systems it may not trust.
It therefore needs controls that help restrict inappropriate operations.
Depending on the architecture, these may include:
- TLS configuration for protected communication.
- Access controls for administrative and restricted resources.
- Request-size and rate limits.
- Secure filesystem permissions.
- Up-to-date server software.
- Appropriate logging and monitoring.
- Restrictions on unsupported methods or unwanted traffic.
- Security controls at a firewall, reverse proxy, or application layer.
A firewall can help control which network traffic is permitted to reach the server.
However, a firewall cannot compensate for every application vulnerability.
For example, if a publicly accessible application accepts malicious input and processes it unsafely, additional application-level protections are still necessary.
The server should also avoid exposing sensitive configuration files, credentials, and internal services through unintended URL mappings.
Why Do Web Servers Return Errors?
An HTTP error response indicates that a request could not be handled as expected under the relevant conditions.
Some errors relate to the requested resource or permissions.
Others relate to server failures, unavailable backends, or upstream communication problems.
| Status | Meaning | Possible Scenario |
|---|---|---|
| 403 Forbidden | Request is refused | The server denies access to a resource |
| 404 Not Found | Resource not found | No matching resource or application route exists |
| 500 Internal Server Error | Server encountered an unexpected failure | Application processing fails |
| 502 Bad Gateway | Gateway or proxy received an invalid upstream response | Reverse proxy cannot obtain a valid response from its backend |
| 503 Service Unavailable | Server cannot currently handle the request | Maintenance or temporary overload |
| 504 Gateway Timeout | Gateway or proxy did not receive a timely upstream response | Backend fails to respond within the applicable timeout |
The distinction between these errors matters.
What Causes a 404 Error?
A 404 Not Found response means the server did not find the requested resource or is not willing to disclose its existence.
For example, the visitor may request a page that has been removed.
It may also result from an incorrect application route or rewrite configuration.
A 404 is an HTTP response, not necessarily a failure of the internet connection or DNS.
What Causes a 502 Bad Gateway Error?
A 502 Bad Gateway response is commonly generated when a gateway or reverse proxy receives an invalid response from an upstream server.
For example, NGINX may be operating correctly as a public-facing web server while the backend application is not communicating as expected.
MDN’s 502 Bad Gateway reference defines this status in terms of an invalid upstream response.
A 502 does not prove that the visitor’s browser or local internet connection is responsible.
What Causes a 503 Service Unavailable Error?
A 503 Service Unavailable response indicates that a server is temporarily unable to handle the request.
Common situations include maintenance or overload.
The response may include a Retry-After header indicating when the client should consider trying again.
A 503 can be generated by a frontend server or another system handling the request.
What Causes a 504 Gateway Timeout Error?
A 504 Gateway Timeout occurs when a server acting as a gateway or proxy does not receive a timely response from an upstream server.
For example, the frontend server may have forwarded a request to an application whose processing takes longer than the configured upstream timeout.
The MDN 504 Gateway Timeout reference distinguishes this condition from receiving an invalid upstream response.
A 504 may therefore involve the connection between two servers rather than the entire connection between the visitor and the website.
Why Can a Web Server Be Slow?
A web server can respond slowly for reasons involving its own resources or the systems it depends on.
The delay may occur before response headers are sent or while the response body is being transferred.
Potential causes include:
- Heavy CPU utilization.
- Insufficient available memory.
- Large numbers of active or waiting requests.
- Slow storage operations.
- Long-running application code.
- Slow database queries.
- Unavailable or overloaded upstream services.
- Network congestion between infrastructure components.
- Inefficient configuration or resource delivery.
One useful performance measurement is Time to First Byte (TTFB), which includes the time until the client receives the first byte of the response, incorporating relevant connection, network, and server delays.
TTFB does not measure server processing time alone.
For example, a distant visitor may experience higher TTFB because of network latency even when the application responds quickly.
Likewise, a nearby visitor can experience high TTFB if the backend requires several seconds to generate a response.
Does a Faster Server Make Every Website Faster?
Not necessarily.
A server upgrade can help when the current computing infrastructure is the bottleneck.
But if a webpage contains large images or expensive browser-side JavaScript, increasing server CPU capacity may have limited effect on the final user experience.
Likewise, if the primary delay comes from an external API or database, optimizing the web server alone may not solve the problem.
Effective performance improvements depend on identifying where the delay originates.
Is a Web Server the Same as Web Hosting?
No.
A web server is software or infrastructure responsible for handling web communication.
Web hosting is a service or arrangement that provides the resources needed to operate a website.
Hosting may include:
- Computing capacity.
- Storage.
- Network connectivity.
- Web server configuration.
- Application execution.
- Database services.
- Monitoring and maintenance.
A hosting provider may manage all these components.
Alternatively, a website operator may configure and maintain the web server independently on rented or owned infrastructure.
A web server is therefore one component that can be provided through web hosting.
Can You Run a Web Server on Your Own Computer?
Yes.
A laptop or desktop computer can run web server software.
For example, developers often run local HTTP servers to test websites.
If the computer listens only on a local interface, the website may be accessible only from that computer.
If configured on a private network, other devices on the LAN may be able to access it.
Making the service available on the public internet requires suitable addressing, network routing, firewall configuration, and secure operation.
Some residential internet services also impose network or contractual restrictions that affect public server hosting.
A dedicated hosting provider is not required by the HTTP protocol, but it is often more practical for maintaining a reliably available public website.
Does Every Website Have One Web Server?
No.
A small website may be served by one server instance.
A larger site may use multiple web servers, application services, databases, and caching systems across different locations.
Visitors may connect first to a CDN or reverse proxy rather than directly to the origin.
Some platforms use managed or serverless services where the website operator does not manage a persistent web server process.
Nevertheless, HTTP requests still need to be handled by some service capable of providing an appropriate response.
The important distinction is between the HTTP server function and a particular physical machine.
One physical computer can run several web server instances, while one website can rely on many independent systems.
A Web Server Turns Requests into Responses
A web server works by listening for web traffic, receiving HTTP requests, selecting the appropriate website or application, and returning responses.
For static resources, it may retrieve and send existing files.
For dynamic resources, it may forward requests to application software that generates content using databases or other services.
Virtual hosting allows multiple websites to share infrastructure. Reverse proxies route traffic toward applications. Caching reduces repeated work, while concurrency mechanisms allow many connections to be managed efficiently.
These capabilities make web servers a fundamental part of modern websites.
The essential mechanism is simple: a client asks for a resource or operation, and the web server determines how to produce or obtain the response that goes back to that client.