Por qué los desarrolladores pros dejan localhost:3000 y usan dominios reales

Recientemente presenté una herramienta interna a mis compañeros. El tool funcionaba perfecto. Pero nadie habló de eso. Todos preguntaban por el dominio. "¿Cuánto te costó www.internaltool.com?". Algunos creían que lo compré solo para la demo. Otros pensaban que tenían acceso VIP.

La realidad es simple. No gasté nada. Todo corría en mi máquina local. Solo cambié el puerto por un dominio real.

El lío de los puertos en desarrollo

Los servidores embebidos en Node.js o Rails nos facilitaron la vida. Un npm start y ya tienes tu app en puerto 3000. Sin complicaciones.

Pero hay un precio. Con varios proyectos abiertos, cada uno en un puerto distinto (3000, 3001, 8080...), terminas memorizando números. Olvidas el código. Peor aún: tu entorno local no se parece al de producción. Ahí se esconden los bugs.

La técnica clásica que sigue vigente

Antes, los devs usaban dominios personalizados en local. Los mapearon con el archivo hosts y un proxy inverso como Nginx. No era solo por estilo. Era para replicar la producción en tu PC.

Ventajas claras: URLs pro, menos confusiones en equipo, claridad mental y un setup que mirrors el real.

Guía paso a paso para dominios locales

1. Edita el archivo hosts

Este archivo es tu DNS personal. Le dice a tu máquina dónde buscar antes de ir a internet.

Ubicación:

• macOS/Linux: /etc/hosts
• Windows: C:\Windows\System32\Drivers\etc\hosts

Abre con permisos de admin. Agrega entradas así:

127.0.0.1 miapp.com
127.0.0.1 dev.miapp.com
127.0.0.1 qa.miapp.com

Listo. Tu navegador resuelve estos a tu localhost.

2. Configura Nginx como proxy inverso

Tu app corre en puerto 3000. El navegador pide puerto 80. Nginx une ambos mundos. Escucha en 80 y redirige al puerto correcto.

Edita el archivo de config de Nginx (en /etc/nginx/sites-available/ por ejemplo). Agrega bloques como estos:

server {
    listen 80;
    server_name miapp.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

server {
    listen 80;
    server_name dev.miapp.com;

    location / {
        proxy_pass http://localhost:3001;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

server {
    listen 80;
    server_name qa.miapp.com;

    location / {
        proxy_pass http://localhost:3002;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Reinicia Nginx:

# macOS
brew services restart nginx

# Linux
sudo systemctl restart nginx

Abre miapp.com en el navegador. Accedes a tu puerto 3000 con dominio pro.

Truco para WSL2

En WSL2, el IP virtual de Linux difiere del host Windows. Consíguelo con:

wsl hostname -I

Saldrá algo como 172.x.x.x. Úsalo en el hosts de Windows:

172.x.x.x miapp.com
172.x.x.x dev.miapp.com

Razones de peso para hacerlo

No es solo maquillaje. Hay beneficios reales.

Paridad de entornos. Tu local ahora usa proxy como en producción. Los bugs salen a la luz antes.

Comunicación en equipo. Di "ve a dev.miapp.com" en vez de "puerto 3000". Menos errores, más pro.

Menos ruido mental. Navegas dominios reales, como siempre.

Mentalidad profesional. Separa a quien hace prototipos rápidos de quien arma workflows sólidos.

Un truco eterno

Esta práctica existe hace años. La comodidad la opacó. Pero invertir 20 minutos vale oro. Mejora tu flujo y te deja enfocarte en código top.

La próxima vez que te pregunten por qué no usas localhost:3000, responde con hechos. Piensas como un dev serio.