¿Qué es un servidor web? Nginx, Apache y Node

Cada vez que abres un sitio, algo al otro lado recibe la petición del navegador y decide qué devolver. Ese algo es el servidor web. A veces es Nginx entregando un archivo HTML, a veces Apache ejecutando PHP, a veces tu propio código Node.js respondiendo JSON.

Entender qué hace el servidor web explica muchas cosas que parecen magia: por qué un sitio estático es barato de alojar, por qué aparece un error 502 cuando la aplicación se cae y por qué tanta gente pone un Nginx delante de Node.

¿Qué es un servidor web?#

Un servidor web es un programa que escucha en un puerto de red, recibe peticiones HTTP y devuelve respuestas HTTP. La respuesta puede ser un archivo que ya existe en el disco (HTML, CSS, una imagen), una página generada al momento por una aplicación o datos para una API.

El término también se usa para la máquina donde corre ese programa. En la práctica, cuando alguien pregunta "¿qué servidor web usas?", la respuesta es un software: Nginx, Apache, Caddy o el servidor que trae tu lenguaje.

Por defecto, HTTP usa el puerto 80 y HTTPS el puerto 443. En desarrollo es habitual ver puertos como 3000 u 8080, porque en Linux los puertos por debajo de 1024 exigen privilegios especiales.

¿Cómo funciona un servidor web por dentro?#

El ciclo de una petición sigue casi siempre los mismos pasos:

1. Escuchar. El servidor abre un puerto y espera conexiones TCP.
2. Aceptar y descifrar. Llega una conexión. Si es HTTPS, el servidor hace el handshake TLS con el certificado del dominio.
3. Leer la petición. Método (GET, POST), ruta (/productos/42), cabeceras (Host, Cookie, Accept) y, a veces, un cuerpo.
4. Decidir qué hacer. Por la cabecera Host, elige qué sitio atender. Por la ruta, decide si lee un archivo del disco o reenvía la petición a una aplicación.
5. Responder. Envía el código de estado (200, 404, 500), las cabeceras (Content-Type, Cache-Control) y el cuerpo.
6. Registrar. Escribe una línea en el log de acceso, con IP, ruta, estado y tiempo.

Un intercambio real, simplificado:

GET /index.html HTTP/1.1
Host: ejemplo.com
Accept: text/html

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1256
Cache-Control: max-age=3600

<!doctype html>...

Cuando algo falla en ese camino, el código de estado indica dónde. Un 404 es un archivo o una ruta que no existe; un 502 es el servidor web quejándose de la aplicación que tiene detrás. Los detalles están en errores HTTP 500, 502, 503 y 504.

Servidor estático, servidor de aplicación y proxy inverso: ¿qué diferencia hay?#

El mismo software puede cumplir papeles distintos, y de ahí viene la mayor parte de la confusión:

• Servidor de archivos estáticos. Lee archivos ya hechos del disco y los devuelve tal cual. Rápido y ligero, porque no ejecuta código en cada petición. Es lo que atiende un sitio estático.
• Servidor de aplicación. Ejecuta tu código para construir cada respuesta: consulta la base de datos, aplica reglas, genera HTML o JSON. Una app Express, Django o Laravel cumple este papel.
• Proxy inverso. Se coloca delante de una o varias aplicaciones, recibe la petición del visitante y la reenvía. Suele encargarse de TLS, compresión, caché y reparto de carga. Mira qué es un proxy inverso.

Una configuración habitual combina los tres: Nginx recibe todo en el puerto 443, entrega /static/ directamente desde el disco y reenvía el resto a un proceso Node.js en el puerto 3000.

¿Qué es Nginx?#

Nginx es un servidor HTTP y proxy inverso de código abierto, conocido por atender muchas conexiones con poca memoria. Según su documentación oficial, tiene un proceso maestro, que lee la configuración y mantiene los workers, y varios procesos worker, que atienden las peticiones con un modelo orientado a eventos. El número de workers puede ajustarse a la cantidad de núcleos de la CPU.

La configuración vive en archivos centrales, organizada en bloques server y location. El ejemplo siguiente sirve archivos estáticos y reenvía el resto a una aplicación:

server {
    listen 80;
    server_name ejemplo.com;

    # archivos estáticos desde el disco: /static/logo.png sale de /var/www/static/logo.png
    location /static/ {
        root /var/www;
    }

    # el resto va a la aplicación Node.js
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Después de editar, nginx -t valida la sintaxis y nginx -s reload aplica la configuración. Si la nueva configuración tiene un error, el proceso maestro mantiene la anterior en funcionamiento.

Cuándo usarlo: como proxy inverso delante de aplicaciones, para sitios estáticos, para terminar TLS en un servidor propio (VPS) y para cachear respuestas.

¿Qué es Apache?#

Apache HTTP Server (httpd) es uno de los servidores web más antiguos que siguen en uso amplio. Su arquitectura gira en torno a módulos. Los módulos de multiprocesamiento (MPMs) definen cómo acepta conexiones: prefork (un proceso por conexión, compatible con software antiguo), worker y event (con hilos). En los sistemas modernos, el valor por defecto casi siempre es event.

La función más conocida de Apache es .htaccess: un archivo colocado en una carpeta que cambia la configuración solo de esa carpeta, sin acceso de administrador al servidor. Por eso domina el hosting compartido con PHP y WordPress. La propia documentación recomienda evitar .htaccess cuando tienes acceso a la configuración principal, porque el servidor busca esos archivos en cada carpeta en cada petición, lo que cuesta rendimiento.

Cuándo usarlo: hosting compartido, aplicaciones PHP que ya traen un .htaccess y entornos donde se necesitan reglas por carpeta.

¿Node.js es un servidor web?#

Puede serlo. Node.js trae el módulo node:http, que crea un servidor HTTP completo en pocas líneas. La documentación de Node explica que una aplicación corre en un único proceso, sin crear un hilo por petición, y usa E/S no bloqueante para atender muchas conexiones a la vez.

// servidor.mjs: un servidor web mínimo, sin dependencias
import { createServer } from "node:http";

const port = Number(process.env.PORT ?? 3000);

const server = createServer((req, res) => {
  if (req.url === "/") {
    res.writeHead(200, { "Content-Type": "text/plain; charset=utf-8" });
    res.end("Hola desde el servidor web\n");
    return;
  }
  res.writeHead(404, { "Content-Type": "text/plain; charset=utf-8" });
  res.end("No encontrado\n");
});

// 0.0.0.0 acepta conexiones desde fuera del contenedor, no solo desde la propia máquina
server.listen(port, "0.0.0.0", () => console.log(`Escuchando en el puerto ${port}`));

Ejecútalo con node servidor.mjs y pruébalo con curl -i http://localhost:3000/. En la práctica, casi nadie escribe las rutas a mano: frameworks como Express, Fastify o Next.js funcionan encima del mismo módulo http.

En este modelo, Node es el servidor de aplicación. Puede servir archivos estáticos, pero no está optimizado para eso como Nginx. TLS y la caché suelen quedar en una capa delante.

Nginx, Apache o Node: ¿cuál usar?#

Algunas reglas prácticas:

• Sitio estático puro: cualquier servidor de archivos sirve, y muchos hostings entregan los archivos sin que configures nada. Mira la diferencia entre sitio estático y dinámico.
• App Node.js, Python o Go en un VPS: la aplicación escucha en un puerto interno y Nginx va delante con TLS.
• WordPress o PHP heredado: Apache con .htaccess es el camino con menos fricción.
• Plataforma de hosting de aplicaciones: normalmente el borde de la plataforma hace de proxy inverso y tú solo escribes la aplicación. Entiende la diferencia en hosting web vs hosting de aplicaciones.

Cómo hacerlo en Square Cloud#

El esquema de este artículo, un proxy inverso delante y la aplicación detrás, ya viene armado en Square Cloud. La red de la plataforma hace el papel del Nginx de borde, con CDN Anycast, HTTP/3, WebSockets, WAF y TLS automático, y cada aplicación web recibe un subdominio *.squareweb.app con HTTPS. Tú escribes solo el servidor de aplicación (Express, FastAPI, Django, Laravel u otro) y haces el deploy en un contenedor aislado, entre diversos runtimes, como Node.js, Python y Go. Consulta los runtimes disponibles hoy en Runtimes. La aplicación debe escuchar en 0.0.0.0, en el puerto de la variable PORT, que define la plataforma, y el proxy no corta las conexiones largas: WebSocket y SSE pasan sin buffer.

Si el sitio no tiene código en el servidor, el runtime de sitios estáticos es el servidor de archivos de este artículo, ya configurado: nginx está siempre en ejecución sirviendo tu carpeta, y una actualización (un commit, una subida o una edición en el administrador de archivos) queda en línea al instante, sin nginx -s reload ni reinicio. En una SPA, un vite.html responde a toda ruta que no sea un archivo.

Cada aplicación web necesita al menos 512 MB de la RAM del plan, y el Hobby, desde R$12,49 al mes, sirve para sitios; el dominio personalizado empieza en el Standard. La analítica web sin cookies, incluida en todos los planes, muestra visitas, rutas y códigos de estado recogidos en el servidor, útil para encontrar los 404 y 5xx que devuelve tu aplicación. Mira cómo publicar en la página de Sitios.