Com configurar un servidor intermediari invers amb Nginx pas a pas

Configurar un servidor intermediari invers amb Nginx és una d'aquestes tasques que sembla més intimidant del que realment és. Darrere de quatre fitxers de configuració, un parell d'ordres i una mica d'ordre a l'arquitectura, pots aconseguir que diverses aplicacions s'amaguin darrere d'un sol domini, millorar el rendiment, reforçar la seguretat i fer que la teva infraestructura sigui molt més fàcil d'escalar.

En les següents línies veuràs, amb tot luxe de detalls, què és un proxy invers a Nginx, per què és tan útil i com muntar-lo en diferents escenaris reals: des d'un simple backend al port 5000, a diversos servidors darrere de balanceig de càrrega, passant per WordPress en subcarpetes, entorns amb Kuber Gunicorn i serveis multimèdia com Jellyfin. La idea és que acabis amb una visió molt completa, gairebé de manual de capçalera.

Què és exactament un servidor intermediari invers Nginx?

Un servidor intermediari invers se situa davant dels servidors d'origen (backends) i és l'únic que rep les peticions dels clients. En lloc que l'usuari es connecti directament a Apache, Gunicorn, .NET, Node.js o qualsevol altre servei, la connexió s'estableix amb Nginx, que actua com a “porter”: decideix a quin servidor enviar la sol·licitud, recull la resposta i la torna al client.

Això és just el contrari d'un servidor intermediari de reenviament, que es fa servir des del costat del client per ocultar la seva IP o saltar restriccions geogràfiques. En un servidor intermediari de reenviament , l'usuari parla amb el servidor intermediari, i aquest es connecta a Internet per ell. En un servidor intermediari invers , l'usuari no veu els servidors d'origen, només el servidor intermediari que hi ha davant del lloc web o l'aplicació.

En el cas de Nginx, a més de servidor web, és un servidor intermediari invers d'alt rendiment que suporta milers de connexions simultànies, amb molt baix consum de memòria. Maneja trànsit HTTP(S), TCP i UDP, i pot treballar amb contingut estàtic, dinàmic i serveis d'API. Amb Nginx Plus, la versió comercial, s'afegeixen més funcions de balanceig, monitoratge avançat i seguretat.

Com funciona un servidor intermediari invers Nginx per dins?

Quan un client fa una petició HTTP, aquesta arriba primer al procés mestre de Nginx i per això un dels processos worker. Nginx examina la sol·licitud (URI, capçaleres, mètode, etc.) i, en funció de les regles de configuració, pren diverses decisions:

• Si el recurs és estàtic i està disponible en disc (per exemple /static/, /images/ o /css/), pot servir directament, o fins i tot des del seu propi cau, reduint molt el temps de resposta.
• Si el contingut és dinàmic (PHP-FPM, .NET, Python, Node, etc.), reenvia la petició a un servidor backend a través de la directiva proxy_pass o altres mecanismes com FastCGI.
• Si hi ha balanceig, seleccioneu un dels servidors del grup upstream seguint l'estratègia configurada (round robin, menys connexions, hash d'IP…).

A més, Nginx pot aplicar lògica avançada basada en capçaleres, tipus de contingut o mòduls personalitzats . Això permet, per exemple, decidir a quin backend enviar trànsit mòbil, o com gestionar peticions de certes APIs, o fins i tot actuar com a passarel·la API en arquitectures de microserveis i Kubernetes (com Ingress Controller).

Mètodes de selecció de backend i equilibri de càrrega

Un dels punts forts de Nginx com a proxy invers és la seva capacitat de distribuir la càrrega entre diversos servidors definides en un bloc upstream. Entre els algorismes més habituals hi ha:

• Round robin (rotatori): reparteix les peticions de manera seqüencial entre tots els servidors. És simple i funciona bé quan els backends tenen característiques similars.
• Least connections (menys connexions): envia la petició al servidor amb menys connexions actives en aquell moment, ideal per connexions de llarga durada, websockets o streaming.
• hash IP: calcula un hash de la IP del client perquè sempre acabi al mateix servidor. Això ajuda a mantenir la persistència de sessió quan aquesta no es gestiona de manera centralitzada.

Aquestes tècniques es poden combinar amb altres ajustaments com timeouts, reintents i regles de next upstream (proxy_next_upstream) per manejar fallades temporals d'un backend sense tirar a baix tot el servei.

Avantatges d'usar Nginx com a proxy invers

Muntar un proxy invers davant de les teves aplicacions té una llista de beneficis força llarga, i amb Nginx s'espremen gairebé tots. Resumidament, t'aporta rendiment, seguretat, flexibilitat i observabilitat.

Seguretat millorada i capa de protecció

Un dels papers fonamentals del proxy invers és actuar com a buffer protector davant d'Internet . Els clients mai no veuen les IP reals dels teus servidors backend; només coneixen la IP o el domini del servidor intermediari. Això complica força la vida a qui intenti atacar directament la teva infraestructura.

A sobre d'això, pots utilitzar Nginx per acabar connexions TLS/SSL (terminació SSL/TLS), implementar autenticació HTTP bàsica, aplicar capçaleres de seguretat (X-Frame-Options, X-Content-Type-Options, X-XSS-Protection, HSTS, etc.) i combinar-ho amb tallafocs de xarxa (UFW, iptables) o WAF externs. Enfront d'atacs DDoS o escanejats massius, el proxy és el que rep el primer cop, i amb limitació de velocitat (limit_req) i controls de connexió pots mitigar força mal.

Alt rendiment, memòria cau i compressió

Nginx és extremadament eficient servint contingut estàtic des de disc o memòria cau. Amb directives com proxy_cache y proxy_cache_path pots emmagatzemar respostes dels backends i tornar-les als clients sense recalcular al servidor d'origen, alleujant càrrega i millorant els temps de TTFB.

A més, és molt freqüent combinar Nginx amb Varnish o amb la memòria cau FastCGI per a PHP, o amb sistemes de memòria cau integrats en CDNs. També es pot activar compressió gzip o Brotli al servidor intermediari per estalviar ample de banda i fer més ràpida l'entrega d'HTML, CSS, JS o JSON.

Escalabilitat i arquitectura distribuïda

Si el vostre lloc comença a rebre molt de trànsit, un sol servidor d'origen no és suficient. Un servidor intermediari invers com Nginx et permet escalar horitzontalment : afegeixes més backends darrere d'un mateix domini i Nginx reparteix el trànsit entre ells. D'aquesta manera evites punts únics de fallada i pots passar d'una arquitectura simple a un clúster amb balanceig de càrrega.

En entorns avançats s'usa fins i tot Global Server Load Balancing (GSLB) , combinant Nginx i CDNs que trien el node més proper a l'usuari usant tècniques com anycast. Això redueix latències, millora lexperiència dusuari i augmenta la disponibilitat.

Integració amb WordPress, aplicacions .NET, Python i més

Un avantatge molt pràctic del servidor intermediari invers és que permet unificar diversos serveis sota el mateix domini encara que estiguin en servidors o tecnologies diferents. Per exemple:

• Un lloc corporatiu estàtic a example.com allotjat al servidor A.
• Un bloc a WordPress a example.com/blog allotjat al servidor B (Kinsta, per exemple).

Amb Nginx pots configurar un bloc location /blog que redirigeixi per proxy al servidor B, de manera que l'usuari sempre hi veu example.com/blog, però el contingut se serveix des duna altra màquina. Això té interès tant per SEO (treballar amb subcarpetes en lloc de subdominis) com per manteniment.

El mateix patró aplica a aplicacions ASP.NET Core que escolten al port 5000, serveis Python servits amb Gunicorn, Node.js amb Express, PHP-FPM o APIs de microserveis. Nginx es queda al port 80/443, i la resta de serveis viu a ports interns més lletjos però segurs.

Requisits previs per muntar Nginx com a proxy invers

Abans de ficar-te amb la configuració, convé tenir uns mínims clars perquè no es torni tot una cadena d'errors:

• Accés al servidor: necessitaràs permisos root o sudo al teu VPS o màquina per instal·lar paquets i editar configuracions.
• Nom de domini apuntant al teu IP: l'ideal és tenir un registre A o CNAME apuntant a la IP pública on està Nginx, per accedir amb https://tudominio.com en lloc de amb una IP.
• Backends funcionals: el teu servidor Apache, Gunicorn, .NET, Jellyfin, etc. ha d'estar aixecat i escoltant al port corresponent abans de posar Nginx davant.
• Firewall ben configurat: a UFW oa un altre firewall has de permetre trànsit a ports 80 (HTTP) i 443 (HTTPS), i òbviament el port d'administració SSH.
• Coneixements bàsics de sintaxi Nginx: entendre blocs http, server, location i l'estructura de directoris /etc/nginx t'estalviarà molts ensurts.
• Certificats SSL: no és obligatori, però sí molt recomanable utilitzar Let's Encrypt (amb Certbot) o un altre proveïdor per habilitar HTTPS amb Nginx al teu domini.

Estructura de configuració de Nginx i arxius clau

A la majoria de distribucions Linux (Ubuntu, Debian, etc.), la instal·lació de Nginx crea una estructura estàndard de directoris de configuració en /etc/nginx que convé respectar per no fer un embolic impossible de mantenir.

• /etc/nginx/nginx.conf: fitxer de configuració principal. Defineix paràmetres globals i dins del bloc http { } inclou altres fitxers mitjançant directives include.
• /etc/nginx/sites-available/: aquí es guarden les configuracions de cada lloc o host virtual. Pots tenir diversos fitxers, un per domini o per servei.
• /etc/nginx/sites-enabled/: conté enllaços simbòlics als llocs que vols que Nginx carregui realment. El més habitual és activar un lloc amb ln -s des de sites-available.
• /etc/nginx/conf.d/: se solen col·locar configuracions globals o fragments que es carreguen per a tots els llocs. Qualsevol fitxer .conf en aquest directori s'hi inclou automàticament.
• /etc/nginx/snippets/: en moltes guies modernes es fan servir “snippets” per trossos reutilitzables de configuració, per exemple capçaleres de seguretat, paràmetres de proxy o límits de taxa.

Dins el bloc http en nginx.conf es defineixen també detalls com registres, memòria cau i compressió. És freqüent veure alguna cosa de l'estil: include /etc/nginx/sites-enabled/*; o include /etc/nginx/conf.d/*.conf; per tenir-ho tot modularitzat.

Directives essencials per a proxy invers

En un escenari típic de proxy amb Nginx les directives clau que veuràs són:

• server: defineix un bloc de servidor virtual. Aquí s'indiquen listen, server_name, root i diversos location.
• location: especifica què cal fer amb les peticions que coincideixen amb un patró d'URI. Pots fer servir /, /blog, /static/, expressions regulars, etc.
• proxy_pass: la peça central per reenviar peticions a un backend. Accepta HTTP o HTTPS i fins i tot noms de grups upstream.
• proxy_set_header: permet reenviar informació important al backend, com el host original, la IP real del client, esquema (http/https), etc.
• proxy_cache y proxy_cache_path: s'usen per habilitar emmagatzematge en memòria cau de respostes dels backends.
• proxy_buffering, proxy_buffer_size, proxy_read_timeout, proxy_connect_timeout, proxy_send_timeout: ajusten buffers i temps despera per controlar latències i temps morts.

Instal·lació i gestió bàsica de Nginx a Ubuntu

A Ubuntu i derivades, Nginx s'instal·la amb el gestor de paquets APT. El seu fort és, primer, actualitzar el sistema per evitar conflictes i tenir els últims pegats:

sudo apt update
sudo apt upgrade -y
sudo apt install nginx -y

Després de la instal·lació, el servei Nginx es registra com un daemon gestionat per systemd, igual que a Windows es gestionen serveis. El controles amb systemctl:

• Comprovar estat: sudo systemctl status nginx
• arrencar: sudo systemctl start nginx
• aturar: sudo systemctl stop nginx
• reiniciar: sudo systemctl restart nginx
• Recarregar configuració sense tallar connexions: sudo systemctl reload nginx
• Habilitar inici automàtic en arrencar: sudo systemctl enable nginx
• Deshabilitar inici automàtic: sudo systemctl disable nginx

Per a una primera prova, només cal fer un curl localhost o obrir la IP del servidor en un navegador; hauríeu de veure la pàgina per defecte de Nginx escoltant al port 80.

Firewall amb UFW

Si utilitzes UFW (Uncomplicated Firewall), hauràs de permetre els perfils de Nginx adequats per habilitar HTTP i HTTPS:

sudo ufw allow 'Nginx Full'
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

El perfil “Nginx Full” obre 80 i 443 , que són els ports típics de les peticions web.

Configurar Nginx com a proxy invers senzill

Veurem l'estructura habitual perquè Nginx escolti al port 80 i vaig enviar peticions a un backend HTTP en un altre host o port. A /etc/nginx/sites-available/ crees un fitxer per al teu domini, per exemple example.com:

server {
listen 80;
server_name example.com www.example.com;
location / {
proxy_pass http://your_backend_server_ip:5000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_redirect off;
}
}

Aquest bloc fa que totes les peticions a example.com al port 80 es manen al backend definit a proxy_pass (Per exemple, http://127.0.0.1:5000 o la IP d'un altre servidor).

Per activar el lloc, creeu l'enllaç simbòlic a sites-enabled i vàlides la configuració:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Proxy invers en una subruta concreta

Si vols reenviar només un subdirectori, com /example o /blog, pots fer servir un bloc location específic dins del mateix server:

location /example {
proxy_pass https://example.com;
}

Això fa que totes les peticions a /example s'enviïn a https://example.com. Aquest enfocament s'utilitza molt per unificar un bloc extern, un tauler de control o un servei SaaS dins del mateix domini principal.

Contingut estàtic, memòria cau i ajustaments de proxy

Per millorar rendiment i evitar que els backends s'empassin peticions innecessàries, és força comú servir arxius estàtics directament amb Nginx i només reenviar allò dinàmic al backend.

Un exemple típic:

server {
listen 80;
server_name example.com;
location / {
proxy_pass http://your_backend_server_ip;
}
location /static/ {
root /path/to/static/files;
expires 30d;
}
}

En aquest cas, tot el que vagi /static/ se serveix des de disc amb una capçalera de memòria cau de 30 dies, descarregant el backend d'haver de gestionar aquests fitxers.

A més pots afinar amb directives de proxy com:

• proxy_buffering: si la desactives (proxy_buffering off;) a certs endpoints pots reduir latència en respostes streaming o websocket-like.
• proxy_buffer_size: defineix la mida del primer buffer de resposta, útil per controlar memòria i rendiment.
• Timeouts de connexió: proxy_connect_timeout, proxy_read_timeout, proxy_send_timeout per gestionar backends lents.
• proxy_ssl i capçaleres: quan el backend és a HTTPS, s'ajusten proxy_pass https://... i les capçaleres X-Forwarded-Proto, Per exemple proxy_set_header X-Forwarded-Proto https;.

Balanceig de càrrega amb blocs upstream

Per repartir trànsit entre diversos backends es defineix un bloc upstream i després s'utilitza aquest nom a proxy_pass. Per exemple:

upstream myapp_backend {
server backend1.example.com;
server backend2.example.com;
}

servidor {
escolta 80;
nom_servidor example.com;
ubicació / {
proxy_pass http://myapp_backend;
proxy_next_upstream error timeout;
}
}

Aquí Nginx distribuirà peticions entre backend1 i backend2 amb round robin, i si detecta errors o timeouts passarà al següent servidor gràcies a proxy_next_upstream. Això serveix tant per a llocs web d'alt trànsit com per a API o serveis interns.

Configuracions avançades: seguretat, límits i TLS

En entorns més seriosos, a més de basic proxy, es munten fragments de configuració específics per a seguretat, paràmetres de proxy i limitació de peticions. És una forma elegant de centralitzar ajustaments.

Snippets de seguretat i proxy

Imagina que creguis /etc/nginx/snippets/security-headers.conf amb alguna cosa així:

add_header X-Frame-Options "SAMEORIGIN";
add_header X-Content-Type-Options "nosniff";
add_header X-XSS-Protection "1; mode=block";

I un altre arxiu /etc/nginx/snippets/proxy.conf amb paràmetres de timeouts:

proxy_connect_timeout 60s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;

Després, al teu host virtual, pots incloure aquests snippets fàcilment:

server {
listen 80;
server_name jelly.tudominio.com;
include /etc/nginx/snippets/security-headers.conf;
location / {
proxy_pass http://10.10.0.112:8096;
include /etc/nginx/snippets/proxy.conf;
}
}

Així, qualsevol canvi als paràmetres de proxy oa les capçaleres es fa en un sol lloc i afecta tots els virtual hosts que incloguin aquests snippets.

Limitació de velocitat (rate limiting)

Per defensar-te d'abusos de bots o atacs de força bruta, Nginx té directives de limitació de requests per IP. Per exemple, en un snippet rate-limit.conf pots definir:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

Després, en una localització concreta:

location /api/ {
limit_req zone=mylimit;
proxy_pass http://backend_api;
}

Amb això, la mateixa IP no pot realitzar més de 10 peticions per segon a aquesta ruta, cosa que mitiga força les sobrecàrregues brusques.

HTTPS amb Let's Encrypt i Certbot

Per habilitar TLS de forma gratuïta, el combo Nginx + Certbot ja és un estàndard. A Ubuntu sols instal·lar:

sudo apt install certbot python3-certbot-nginx -y

I després emes el certificat i configures Nginx en un sol pas:

sudo certbot --nginx -d example.com -d www.example.com

Certbot s'encarrega de editar el host virtual, afegir el bloc listen 443 ssl, les rutes a fullchain.pem y privkey.pem i configurar la redirecció de HTTP a HTTPS si vols.

La renovació s'automatitza mitjançant un timer de systemd o un cron, que pots comprovar amb alguna cosa com systemctl list-timers | grep certbot.

Cloudflare, túnels i restriccions de ports

De vegades, el vostre ISP pot restringir l'ús dels ports 80 i 443 en connexions domèstiques. Per salvar aquest obstacle, es pot fer servir Cloudflare Tunnel (cloudflared) , que crea un túnel sortint des del teu servidor cap a Cloudflare i exposa el servei sota el teu domini sense necessitat que els ports estiguin oberts cap a Internet.

El flux sol ser:

• instal·les cloudflared en el teu servidor.
• Autentiques l'eina amb el teu compte de Cloudflare.
• Crees un túnel i un fitxer config.yml on defineixes els serveis que exposes (per exemple Jellyfin a http://localhost:8096 associat a jelly.tudominio.com).
• Arrenques el servei cloudflared perquè mantingui el túnel actiu.

En aquest escenari, Nginx pot continuar fent de proxy invers i terminació TLS interna , però Cloudflare controla el trànsit entrant des de la xarxa global, afegeix protecció DDoS i emmascara el teu IP real.

Nginx Proxy Manager i gestió per interfície web

Si no us ve de gust barallar-vos massa amb fitxers de configuració, hi ha l'opció d'utilitzar Nginx Proxy Manager , que és un contenidor amb un panell web on creeu hosts de proxy invers mitjançant formularis. És molt útil per a entorns amb molts contenidors Docker (per exemple, serveis casolans tipus Home Assistant, Jellyfin, etc.).

En aquest cas, el flux bàsic és:

• Engegar el contenidor de Nginx Proxy Manager.
• Accedir al panell, iniciar sessió i afegir un nou Proxy Host indicant subdomini, IP interna del contenidor de destinació i port.
• Configura SSL des de la interfície, normalment també amb Let's Encrypt.

La lògica és idèntica a un clàssic Nginx, però tot es guarda en una base de dades i en configuracions generades automàticament. És especialment pràctic si vols mapejar diversos subdominis a diferents contenidors sense tocar directament /etc/nginx.

Integració amb aplicacions específiques: exemples

ASP.NET Core darrere de Nginx

A molts tutorials de .NET es desplega l'aplicació a Linux, escoltant al port 5000 sense HTTPS. Els objectius són clars: ocultar el port, utilitzar només 80/443 i assegurar-se que l'app es reinicia sola si cau.

La idea és que Nginx rebi tot el trànsit HTTP al port 80 i el redirigeixi a http://localhost:5000. El bloc típic és:

server {
listen 80;
server_name _;
location / {
proxy_pass http://localhost:5000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}

Si en provar amb curl localhost reps un 502 Bad gateway, el més normal és que l'app de .NET no estigui corrent al port 5000. Pots comprovar-ho amb netstat -tlp | grep 5000 o similar i consultar els logs de /var/log/nginx/error.log, on sol aparèixer el missatge que Nginx no pot connectar amb el riu amunt.

Python + Gunicorn i proves de proxy

Un altre cas clàssic de la documentació és muntar un petit servidor Gunicorn per a aplicacions Python i utilitzar Nginx com a façana. Es configura un fitxer wsgi.py que respon amb un 200 OK i es llança Gunicorn amb diversos workers. Nginx s'encarrega de rebre les peticions HTTP públiques i reenviar-les al port on escolta Gunicorn.

Aquest tipus de proves són ideals per comprovar que la teva cadena Nginx → backend funciona correctament abans de desplegar una app complexa. Si veus els logs de Gunicorn movent-se quan fas peticions web, saps que el servidor intermediari invers està redirigint bé.

WordPress en subcarpeta via Nginx o Apache

Al món WordPress, molts proveïdors i agències usen proxies inversos per allotjar el lloc principal en un servidor i el bloc en un altre , però servint tot sota el mateix domini. Per Nginx, una regla típica seria:

location ^~ /blog/ {
proxy_pass http://blog.domain.com;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}

Després, al servidor del bloc, s'ajusten la URL base a la base de dades de WordPress, el wp-config.php perquè sàpiga que està servint baix /blog i les regles de reescriptura (ja sigui a Nginx, Apache o .htaccess). Aquest mateix esquema es pot replicar amb Apache usant les directives ProxyPass y ProxyPassReverse si aquest és el proxy invers que prefereixes.

Registres, depuració i errors típics

Quan alguna cosa va malament, els teus millors amics són els registres d'accés i error de Nginx, normalment a /var/log/nginx/access.log y /var/log/nginx/error.log. El primer et dóna una línia per a cada petició amb mètode, ruta, codi HTTP, mida, etc. El segon recull problemes de connexió amb upstream, errors de DNS, errors de sintaxi en configuració (quan es fa servir nginx -t), Etc

Entre els errors més freqüents hi ha:

• 502 Bad gateway: el backend no està escoltant, ha caigut, o el port/host de proxy_pass és incorrecte.
• 404 inesperats: rutes mal definides a location, arrel de documents (root) equivocada o regles de reescriptura mal aplicades.
• Loops de redirecció a HTTPS: barreja de redireccions a Nginx ia l'aplicació (per exemple, WordPress forçant HTTPS), o capçaleres X-Forwarded-Proto no configurades correctament.
• Permisos de sistema: rutes de memòria cau, sockets o directoris de logs sense permisos per a l'usuari que corre Nginx.

Un truc sa abans de recarregar és executar sempre sudo nginx -t. Si hi ha un punt i coma perdut o una clau mal tancada, aquesta ordre la detecta i t'evita tirar avall el servei.

Amb tot el vist, queda clar que Nginx com a proxy invers és molt més que un simple passamans de peticions: centralitza el trànsit, protegeix els teus backends, els accelera amb memòria cau i compressió, permet balancejar càrrega, integrar serveis dispars sota el mateix domini i controlar amb precisió la seguretat i l'observabilitat ; si a més ho combines amb HTTPS automatitzat mitjançant Let's Encrypt, amb túnels de Cloudflare quan l'ISP es posa pesat i amb eines com Nginx Proxy Manager per a entorns de contenidors, tens una solució molt madura tant per a projectes personals com per a infraestructures d'alta demanda. Comparteix la guia perquè més usuaris coneguin del tema.