Proxy Inverso · 17 min read · Jan 24, 2026
Guía para ejecutar un proxy inverso para HTTP(S), SSH y MySQL/MariaDB usando NGINX
Esta guía te guiará a través de la instalación y configuración de NGINX para permitir la ejecución de múltiples servidores físicos, máquinas virtuales o una combinación de ambos detrás de una única dirección IP pública. Puedes optar por ejecutar varios servidores web en máquinas virtuales y administrarlos localmente o puede que necesites hacer uso de herramientas de acceso remoto como SSH a cada uno de los hosts. Por ejemplo, si el acceso local no estará disponible fuera del horario laboral normal. Esta guía puede facilitar ambos escenarios.
Las configuraciones que se muestran aquí serían más adecuadas para un laboratorio en casa o una red de pequeña empresa que tiene limitaciones en las direcciones IP públicas disponibles. No habría mucha razón, si es que hay alguna, para ejecutar una configuración como esta, cuando tienes múltiples servidores o máquinas virtuales alquiladas de un servicio de alojamiento, se te asignará una dirección IP pública para cada servidor o host de todos modos.
Te mostraré cómo instalar NGINX y hacer configuraciones que permitirán que el servidor actúe como un proxy inverso para HTTP(S), SSH, FTP y MySQL/MariaDB. Presumo que para el servidor host de NGINX tienes: acceso local, una instalación nueva de Ubuntu 18.04 y que optaste por instalar el servidor SSH durante los pasos de instalación del servidor Ubuntu.
Esta configuración funciona bien para mí, pero por favor entiende que no puedo garantizar que esto funcione para ti. Por supuesto, si encuentras algo mal, házmelo saber para que pueda corregirse. Asegúrate de leer toda la guía antes de comenzar, hay una parte (streams) donde muestro dos formas de gestionarlo.
Comenzando
En esta guía, estaré usando los siguientes nombres de host y direcciones IP.
rproxy.example.com 192.168.1.1
web1.example.com 192.168.1.2
db1.exmple.com 192.168.1.3Deberías tener una cuenta de usuario no root en el servidor para una instalación estándar de servidor Ubuntu 18.04 que creaste durante la instalación. Comienza iniciando sesión en el servidor donde instalarás NGINX con ese usuario. Como este es probablemente un servidor local, es posible que necesites iniciar sesión directamente en el servidor la primera vez para configurar el servidor SSH. Por supuesto, necesitarás un teclado y un monitor conectados al servidor para hacer esto.
Nota: Si como yo usas software de virtualización como VMWare que incluye una interfaz de navegador, entonces deberías tener una consola dentro de ese sistema y puedes realizar este paso sin acceso “directo”. Podrías intentar realizar toda esta configuración dentro de esa consola, sin embargo, he encontrado que algunas funciones como copiar y pegar no funcionaron en la consola basada en navegador, aunque esto podría ser específico del navegador, así que podría valer la pena intentar ver si puedes.
Preparando el servidor host
En tu consola shell (navegador o conectado directamente)
sudo nano /etc/ssh/sshd_configDescomenta las líneas: Port cambia el número de puerto a algo como 23456, ListenAddress y cámbialo a 0.0.0.0. Para aquellos que pueden no estar familiarizados con nano, presiona CTRL + X, escribe y, y luego presiona enter. Esto guardará y cerrará un archivo, si no se realizaron cambios en el archivo, CTRL + x cerrará el archivo sin pedir guardar. Volverás al símbolo del sistema.
No profundizaré en el resto de la configuración dentro de este archivo porque esta ya es una guía considerablemente larga y hay muchas guías que te mostrarán qué configuraciones deberías cambiar para una serie de cosas, como usar claves SSH y permitir el inicio de sesión SSH como root. También puedes encontrar esas guías aquí mismo en el sitio web de HowtoForge.
Con los cambios completos, necesitarás reiniciar el servidor ssh para que los cambios surtan efecto. Tu inicio de sesión actual no se ve afectado por este reinicio.
systemctl restart sshVerifica que puedes iniciar sesión usando SSH desde un terminal en otra computadora dentro de tu red local.
ssh [email protected] -p23456Mantén este terminal abierto después de iniciar sesión con éxito usando SSH y cierra sesión en la consola/servidor. Ya no necesitarás usarlo para el resto de esta guía.
A partir de este punto, estarás ejecutando comandos de nivel root desde tu terminal. El siguiente comando eliminará la necesidad de anteponer comandos subsiguientes con sudo.
sudo -sActualiza la base de datos de paquetes Apt y actualiza Ubuntu para asegurarte de que tienes los paquetes más recientes instalados.
apt update && apt -y upgradeSi ves algo durante la actualización que informa que se están instalando nuevos núcleos, entonces deberías reiniciar una vez que apt haya terminado de actualizar para asegurarte de que estás trabajando en un sistema completamente actualizado.
Estableciendo el nombre de host del servidor proxy inverso.
hostnamectl set-hostname rproxy.example.comSi estás ejecutando un servidor virtual, es posible que tengas un archivo llamado cloud.cfg que necesita ser modificado para preservar el nombre de host que se establece aquí. El siguiente comando mostrará un archivo con contenido o una página vacía. Si ves una página vacía, puedes simplemente CTRL + x y omitir este paso ya que no hay nada que debas hacer.
nano /etc/cloud/cloud.cfgCambia la línea de preservar el nombre de host a true y cierra/guarda el archivo.
Si tu sistema es actualmente solo local, necesitarás mostrarle a este servidor dónde están tus otros servidores/hosts virtuales.nano /etc/hostsEl archivo hosts se verá algo así después de que realices los cambios, las direcciones IP y los hosts deben coincidir con tu propia infraestructura.
127.0.0.1 localhost
127.0.1.1 rproxy.example.com
192.168.1.2 web1.example.com
192.168.1.3 db1.example.com
# Las siguientes líneas son deseables para hosts compatibles con IPv6
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allroutersInstalando NGINX
apt install -y nginxDespués de la instalación, deberías verificar tu versión de NGINX, es fundamental que tengas una versión 1.9 o superior para permitirte hacer proxy inverso para SSH y MySQL/MariaDB.
nginx -vComo puedes ver, tengo instalada la versión 1.14 de NGINX, que es la predeterminada en Ubuntu 18.04 (10 de octubre de 2019)
nginx version: nginx/1.14.0 (Ubuntu)Preparando NGINX para funcionar como un Proxy Inverso
Con esta configuración, no vas a servir ningún sitio web directamente desde el servidor host del proxy inverso. Crearás una nueva estructura de directorios bajo /etc/nginx/. Esto preservará las configuraciones predeterminadas de NGINX en caso de que desees revertir estos cambios más tarde o decidas que realmente también deseas servir sitios web directamente desde este host. Es posible ejecutar la configuración predeterminada junto con estas configuraciones de proxy inverso, sin embargo, si Apache2 estará en el mismo servidor, necesitará puertos alternativos para escuchar y aún necesitarás hacer proxy inverso a los sitios web que esta instancia de Apache2 sirva.
Construyendo la estructura de directorios del proxy inverso
cd /etc/nginx && mkdir rproxy && cd rproxy && mkdir http http/available http/enabled stream stream/available stream/enabledAhora que tienes la estructura en su lugar, puedes proceder a crear los archivos de configuración. Uso nano, pero puedes usar el editor con el que te sientas cómodo. Nano creará/actualizará los archivos al guardar.
Antes de proceder, abre un documento vacío en tu computadora o toma un bolígrafo y papel para anotar los puertos que configures.Configurando proxies inversos de servidor web (http)
Crea el archivo(s) de configuración http para el(los) sitio(s) web ajustando según sea necesario
nano http/available/example.com.confCopia el bloque del servidor en la página abierta en el terminal con nano ajustando según sea necesario.
# Anota los puertos 80 y 443
server {
server_name example.com www.example.com;
listen 80;
set $upstream 192.168.1.2;
location / {
proxy_pass_header Authorization;
proxy_pass http://$upstream;
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_http_version 1.1;
proxy_set_header Connection "";
proxy_buffering off;
client_max_body_size 0;
proxy_read_timeout 10000s;
proxy_redirect off;
}
}Configurando proxies inversos de SSH, MySQL/MariaDB (stream)
Antes de proceder, decide cuál deseas utilizar, por host o por servicio. Por host, crearás una configuración para cada host que podría ser útil para cambiar rápidamente la configuración de un solo host. Por servicio, tendrás los puertos de servicio para todos los servidores en un archivo para cada uno, SSH, MySQL/MariaDB y FTP.
Usando configuraciones por servicio
Agrega las configuraciones de SSH.
nano stream/available/ssh.conf# Anota los puertos de escucha
upstream web1-ssh {
server 192.168.1.2:22;
}
server {
listen 22002;
proxy_pass web1-ssh;
}
upstream db1-ssh {
server 192.168.1.3:22;
}
server {
listen 22003;
proxy_pass db1-ssh;
}
# Agrega tantos pares de bloques upstream y server como necesites para tus servidores SSH accesados de forma remota.Agrega las configuraciones de MySQL/MariaDB.
nano stream/available/db.conf# Anota los puertos de escucha
upsteam db1-mysql {
server 192.168.1.3:3306;
}
server {
listen 33063;
proxy_pass db1-mysql;
}
# Agrega tantos pares de bloques upstream/server como necesites para tus servidores MySQL/MariaDB accesados de forma remota a este archivo.Ahora crea las configuraciones de proxy inverso FTP.
nano stream/available/ftp.confupstream web1-ftp {
server 192.168.1.3:21
}
server {
listen 21002;
proxy_pass web1-ftp;
}
# Agrega tantos pares de bloques upstream/server como necesites para tus servidores FTP accesados de forma remota.Usando archivos de configuración por host
nano /etc/nginx/rproxy/stream/available/web1.example.com.conf# Anota los puertos de escucha
upstream web1-ssh {
server 192.168.1.3:22;
}
server {
listen 22002;
proxy_pass web-ssh;
}
Creando el archivo de host para db1.example.com
nano /etc/nginx/rproxy/stream/available/db1.example.com.conf# Anota los puertos de escucha
upsteam db1-mysql {
server 192.168.1.3:3306;
}
server {
listen 33063;
proxy_pass db1-mysql;
}
upstream db1-ssh {
server 192.168.1.3:22;
}
server {
listen 22003;
proxy_pass db1-ssh;
}
Como puedes ver, es un poco poco ortodoxo. Estás usando puertos públicos de una manera no estándar, eligiendo los puertos que necesitas y luego apuntándolos a NGINX. Esto sería normal excepto que ahora estás usando un puerto diferente para cada servicio en cada servidor que deseas acceder de forma remota. Esto significa, usando SSH como ejemplo, un número de puerto diferente para cada host habilitado para SSH 22 222 2222 22222, por ejemplo, apuntaría al puerto 22 en cuatro servidores o máquinas virtuales diferentes.
Este no es el caso para NGINX para hacer proxy inverso para sitios web, siempre que NGINX tenga una configuración de servidor definida para un sitio web funcionará correctamente con solo los puertos 80 y 443 redirigidos a él.
En este punto, probablemente te has dado cuenta de que podrías simplemente usar los pasos de HTTP y omitir los pasos de stream, y en su lugar redirigir múltiples puertos para los múltiples servicios a el servidor/dirección IP apropiada. De hecho, esto se puede hacer. Sin embargo, añadiría otra capa de complejidad y se volvería difícil de mantener a medida que aumenta el número de servidores porque podrías necesitar cambiar los puertos predeterminados en cada servidor para ssh, mysql y ftp. Esta configuración ya es compleja, aún así podría hacerse si lo deseas.
Usar un proxy inverso para estos servicios de la manera que te he mostrado reduce significativamente la complejidad al proporcionar un solo lugar para hacer estos cambios de configuración y no necesitarías hacer cambios en los puertos en toda tu infraestructura.
Como un bono adicional a esta configuración, los otros servidores en tu infraestructura solo necesitan escuchar en interfaces locales y puertos de servicio predeterminados si eso es lo que prefieres. Si estás gestionando localmente, puedes usar las direcciones IP locales y los puertos de servicio predeterminados para acceder a los servicios requeridos, así que no necesitarás consultar tus notas para recordar los puertos correctos, solo necesitas conocer la dirección IP y las credenciales de inicio de sesión.
Uniendo todo
Para comenzar a usar las configuraciones de proxy inverso de NGINX necesitarás hacer algunas ediciones al archivo de configuración principal. Comenta la línea de inclusión actual en el bloque http (si no estás sirviendo sitios web directamente desde NGINX también).
cd /etc/nginx && nano nginx.confNota las partes resaltadas a continuación para determinar qué necesita cambiar.
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
events {
worker_connections 768;
# multi_accept on;
}
http {
##
# Configuraciones Básicas
##
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# Configuraciones SSL
##
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Eliminando SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;
##
# Configuraciones de Registro
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
##
# Configuraciones Gzip
##
gzip on;
gzip on;
# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascri$
##
# Configuraciones de Host Virtual
##
include /etc/nginx/conf.d/*.conf;
# include /etc/nginx/sites-enabled/*;
# Archivos de configuración de proxy inverso http.
include /etc/nginx/rproxy/http/enabled/*.conf;
}
stream {
# Archivos de configuración de proxy inverso stream.
include /etc/nginx/rproxy/streams/enabled/*.conf;
}
#mail {
# # Ver script de autenticación de muestra en:
# # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
#
# # auth_http localhost/auth.php;
# # pop3_capabilities "TOP" "USER";
# # imap_capabilities "IMAP4rev1" "UIDPLUS";
#
# server {
# listen localhost:110;
# protocol pop3;
# proxy on;
# }
#
# server {
# listen localhost:143;
# protocol imap;
# proxy on;
# }
#}
Activar las configuraciones de proxy inverso.
Primero, habilita todas las configuraciones http
ln -s /etc/nginx/rproxy/http/available/*.conf /etc/nginx/rproxy/http/enabledHabilita todas las configuraciones de stream
ln -s /etc/nginx/rproxy/stream/available/*.conf /etc/nginx/rproxy/stream/enabledRealiza una prueba para verificar que la configuración de NGINX como proxy inverso es correcta.
nginx -TEn la salida, deberías ver un mensaje de éxito junto con todas las configuraciones personalizadas que has realizado anteriormente.
Reinicia NGINX para poner en acción las configuraciones de proxy inverso.
systemctl restart nginxVerifica que NGINX esté escuchando en todos los puertos configurados. verifica contra tus notas que todos los puertos se muestren en los resultados.
netstat -tulpn | grep nginxLa salida debería verse algo así
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:22002 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:22003 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:33062 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:33063 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 4964/nginx: master Abriendo el servidor para tráfico
Ahora que NGINX está escuchando y listo para actuar como proxy inverso para todas las conexiones que queremos permitir el tráfico, desactiva temporalmente UFW mientras pasas por los siguientes pasos. Será más fácil solucionar problemas si las cosas no están funcionando correctamente.
ufw disableRedirigiendo Puertos
Desafortunadamente, no puedo darte orientación aquí. Necesitarás consultar el manual de tu enrutador o buscar en línea para aprender cómo hacer esto. En resumen, sin embargo, deseas redirigir cada uno de los puertos en los que NGINX está escuchando a la máquina host de NGINX. En mi enrutador específico, puedo configurar “aplicaciones” personalizadas.
Esto me permite asignar cualquier número de puertos no asignados o rangos de puertos a la aplicación personalizada que luego se asignará a una dirección IP LAN o a un dispositivo conectado específico identificado por su nombre de host. En cualquier caso, esto significa que puedo cambiar todos los puertos asignados a esa aplicación personalizada a cualquier host en mi red sin tener que eliminar todos los puertos y reasignarlos. Esta es una excelente opción y recomiendo encarecidamente que elijas un enrutador que lo soporte.
Esta pequeña pero increíblemente útil característica en el firewall de mi enrutador me llevó a instalar un segundo proxy inverso reflejando las configuraciones de mi proxy inverso activo. Lo tengo apagado y puedo iniciarlo y tener los puertos cambiados a él en menos de 3 minutos de descubrimiento. Imagino que hay empresas de alojamiento profesional que tendrían dificultades para cumplir con ese tiempo de respuesta para la recuperación ante desastres y todo esto surgió por el deseo de ejecutar múltiples servidores en una red doméstica.
SSL gratuito de Letsencrypt para el servidor proxy inverso
Instala Certbot y el complemento Certbot NGINX. Este paso se realiza aquí porque no puedes crear un certificado hasta que tengas DNS funcional para todos los nombres (sub.) de dominio listados en un certificado y puedas hacer una conexión al dominio a través de HTTP. Al completar esto después de haber redirigido los puertos al proxy inverso, también actúa como una prueba adicional a tus configuraciones. Si el certificado falla porque el dominio no se puede alcanzar, verás un aviso de error significativo en la salida.
Para asegurarte de que estás obteniendo la última versión de certbot, agrega el repositorio de certbot antes de instalar. Los repositorios de Ubuntu a menudo están una versión o más detrás de una versión de software y realmente deseas las versiones más estables de todo tu software si puedes obtenerlas.
add-apt-repository ppa:certbot/certbot
apt install -y certbot python-certbot-pluginCon certbot y el complemento nginx de certbot instalados, ahora puedes crear los certificados para NGINX.
Este comando debe repetirse para todos los dominios y subdominios para los que deseas proporcionar SSL. Si esta es la primera vez que ejecutas certbot, necesitarás aceptar los términos y condiciones.
certbot --nginx -d example.com -d www.example.comNota que si tienes un servidor en funcionamiento con SSL en el host upstream, necesitarás asegurarte de que las opciones seleccionadas aquí coincidan con las del servidor host, específicamente, si rediriges a https en el servidor upstream, deberías hacerlo aquí también.
Para mayor claridad, example.com existe en otro servidor, y seleccioné redirigir http a https dentro de ISPConfig, así que por esa razón, selecciono hacerlo aquí. El archivo de configuración se actualizará y ahora veo que Certbot ha agregado algunas configuraciones propias.
Verificando que las cosas funcionen.
Ahora que tienes tráfico capaz de fluir hacia tu proxy inverso, deberías verificar que todo esté funcionando como se espera. Verifica que los sitios web funcionen correctamente, realiza conexiones y tareas de SSH, FTP y MySQL/MariaDB. Una vez que estés satisfecho de que todo está funcionando como debería, habilitarás UFW y agregarás reglas para permitir cada uno de los puertos.
Asegurando el servidor proxy inverso
ufw enableQuerrás permitir, 80 y 443 desde cualquier lugar. y probablemente restringir SSH, FTP y MySQL/MariaDB a una dirección IP o nombre de host. Puedes comentar las reglas para identificar rápidamente qué servicio/servidor has asignado al puerto.
ufw allow 80
ufw allow 443
ufw allow from 1.2.3.4 to any port 22002 comment 'web1 SSH'
ufw allow from somehost.domain.com to any port 33061 comment 'db1 MySQL/MariaDB'
ufw reload
ufw status numberedActualizando Apache2
Cuando se ejecuta detrás de un proxy inverso, los archivos de registro de Apache2 registrarán la dirección IP del servidor proxy inverso en lugar de la dirección IP del visitante del sitio web. Para restablecer el registro normal de direcciones IP en Apache2, hay un módulo disponible para corregir este comportamiento.
Completa los siguientes pasos en cada servidor web con una instancia de Apache2 instalada.
sudo apt install -y libapache2-mod-rpafPara asegurarte de que Apache2 ahora registrará las direcciones IP correctas, haz una pequeña modificación al archivo rpaf.conf. Ubuntu 18.04 ya ha creado el archivo por nosotros, solo necesitamos editarlo cambiando la dirección IP resaltada a la del host proxy inverso NGINX.
nano /etc/apache2/mods-available/rpaf.conf
RPAFenable On
# Cuando está habilitado, toma el encabezado X-Host entrante y
# actualiza la configuración del virtualhost en consecuencia:
RPAFsethostname On
# Define qué IP's son tus proxies frontales que envían
# los encabezados X-Forwarded-For correctos:
RPAFproxy_ips 127.0.0.1 ::1
# Cambia el nombre del encabezado a analizar desde el predeterminado
# X-Forwarded-For a algo de tu elección:
# RPAFheader X-Real-IP
Notas Finales
NGINX y Apache2 en el mismo host
No dos servicios pueden escuchar en el mismo puerto dentro de un servidor o máquina virtual. Si NGINX está instalado en el mismo servidor o máquina virtual que un servidor web Apache2, necesitarás cambiar el puerto en el que Apache2 escucha. NGINX requiere puertos 80 y 443 para realizar sus funciones HTTP(S) ya que son los puertos predeterminados para HTTP y HTTPS.
Consulta nuevamente la sección http de esta guía y agrega configuraciones de proxy inverso para los sitios web servidos por esta instancia de Apache2 de la misma manera que la de otros servidores en la red.
Cambiando el puerto de escucha de Apache2
Si tienes un sistema de gestión de servidores instalado como ISPConfig, este sistema maneja los archivos vhost de Apache2, así que deberías investigar cómo cambiar los puertos en los que Apache2 está escuchando. Busca en los foros de ISPConfig y luego haz esos ajustes según sea necesario. De lo contrario, deberías consultar los foros de Ubuntu o el sitio web de Apache2 para cómo realizar estos cambios.
Nota: Los puertos de Apache2 no necesitan ser alterados cuando es el único servidor web instalado en el servidor o máquina virtual.Recibe nuevas publicaciones en tu bandeja de entrada.
No spam. Cancela la suscripción en cualquier momento.