Почему профи-разработчики отказываются от localhost:3000 в пользу настоящих доменов

Недавно я показал коллегам внутренний инструмент. Реакция удивила. Никто не спросил про код. Все интересовались: "Сколько заплатил за домен?" Кто-то думал, что купил его специально для демо. Другие заподозрили whitelist по IP.

На деле — ни копейки. Всё крутилось локально. Просто на www.internaltool.com вместо localhost:3002.

Парадокс современных фреймворков

Node.js, Rails и другие дали нам встроенные серверы. Запустил npm start — и проект жив на порту 3000. Никакой возни с настройкой.

Но цена удобства высока.

Три-четыре проекта одновременно? Порты 3000, 3001, 8080, 5173... Мозг превращается в справочник портов. Забываешь про код. В команде — полный хаос.

Хуже то, что локальная среда не похожа на production. А там прячутся баги.

Старый метод, который не устарел

Раньше серверы не вшивались в приложения. Разработчики мапили домены локально через системные настройки.

Это не про красоту. Это про точную копию production на твоей машине.

Секрет прост: hosts-файл ОС плюс reverse proxy вроде Nginx. Запускаешь кучу проектов на чистых доменах — dev.yourproject.com, qa.yourproject.com. Всё ведёт на разные локальные порты.

Результат: профильные URL, ясная голова, лёгкий шаринг в команде и среда как в проде.

Как настроить локальные домены: полная инструкция

Шаг 1: Редактируем hosts-файл

Hosts — это твой личный DNS. Компьютер смотрит туда первым, прежде чем лезть в сеть. Добавь записи — и myproject.com ведёт на localhost.

Где файл:

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

Открой с правами админа (sudo). Добавь:

127.0.0.1 myproject.com
127.0.0.1 dev.myproject.com
127.0.0.1 qa.myproject.com

Браузер теперь резолвит их на 127.0.0.1.

Шаг 2: Nginx как reverse proxy

Браузер по умолчанию идёт на порт 80. Твой app — на 3000. Несовпадение = фейл.

Nginx слушает 80 и перенаправляет трафик.

Создай или доработай конфиг Nginx (обычно /etc/nginx/sites-available/ на Linux). Пример блоков:

server {
    listen 80;
    server_name myproject.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.myproject.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.myproject.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;
    }
}

Перезапусти Nginx:

# macOS
brew services restart nginx

# Linux
sudo systemctl restart nginx

Готово. Иди на myproject.com — попадёшь на localhost:3000 через нормальный домен.

Фишка для WSL2

В WSL2 Linux имеет свой IP, не 127.0.0.1. Узнай его:

wsl hostname -I

Выдаст что-то вроде 172.x.x.x. Используй этот IP в Windows hosts:

172.x.x.x myproject.com
172.x.x.x dev.myproject.com

Зачем это нужно на самом деле

Казалось бы, косметика. Но нет.

Во-первых, паритет сред. Локалка повторяет production. Если в проде reverse proxy — баги вылезут сразу.

Во-вторых, коммуникация в команде. "Зайди на dev.internaltool.com" — проще, чем "порт 3000".

В-третьих, ясность в голове. Домены как в реальной жизни, без портов.

Наконец, это отличает профи от "быстренько на localhost". Ты думаешь о среде серьёзно.

Навык на века

Метод старый, но забытый ради удобства. Удобство ≠ профизм.

20 минут на настройку — лучшая инвестиция в workflow. Освобождает мозг для главного: хорошего кода.

В следующий раз на вопрос "почему не localhost:3000" ответишь: "Потому что работаю как профи".