#Симптом и границы применимости
Если curl http://127.0.0.1:порт работает, а публичное имя не отвечает, причина может быть в привязке к loopback, DNS, маршрутизации, firewall или публикации сайта в панели. Локальная доступность не означает открытую внешнюю сеть.
Эта инструкция относится к конкретному сайту в панели управления хостингом, когда его обслуживают Nginx, Apache, PHP-FPM или их сочетание. Названия разделов и доступность SSH зависят от установленной панели и прав пользователя; шаги, которых нет в вашем интерфейсе, выполняет администратор сервера.
#Возможные причины и признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Сервис слушает только loopbackВ ss виден 127.0.0.1:порт | С другого узла TCP-подключение не устанавливается | Правильно разместить внешний обратный прокси |
| Неверный DNS/адресДомен указывает не на текущий сервер | Публичный IP отличается от назначенного | Исправить записи или маршрутизацию |
| Сетевые правилаFirewall/облачная группа безопасности отклоняет 80/443 | Внутри работает, извне тайм-аут | Разрешить только нужные порты и источники |
#Пошаговая диагностика и исправление
- Зафиксируйте точную схему публикацииУзнайте, какой компонент должен быть публичным: Nginx/Apache на 80/443 или внутреннее приложение на 127.0.0.1:порт. Не публикуйте напрямую PHP-FPM, базы данных и административные интерфейсы.
- Проверьте локальный ответНа самом сервере сделайте HTTP-запрос к известному локальному порту и запишите код. Если это сервис HTTPS, используйте соответствующую схему; не отключайте TLS для удобства.
- SSH, обычно без прав администратораLinux · Терминал (Bash)КомандаSSH, обычно без прав администратора. 8080 — пример внутреннего HTTP-порта; замените его реальным.
curl -sS -I http://127.0.0.1:8080/
- Найдите фактический слушающий адресС помощью ss проверьте локальный и внешний bind, владельца процесса. Если приложение слушает только 127.0.0.1, это нормально за обратным прокси; открывайте наружу фронтенд, а не внутренний сервис.
- SSH с административными правами для имён процессовLinux · Терминал (Bash)КомандаНужен sudoSSH с административными правами для имён процессов. Показывает все TCP-порты в режиме LISTEN.
sudo ss -ltnp
- Сопоставьте домен и IPПроверьте DNS A/AAAA домена и публичный адрес сервера или балансировщика. Уточните, не включён ли CDN. DNS может ещё кешировать старый адрес после переезда; не меняйте записи без понимания маршрута.
- Проверьте настройки сайта в панелиУбедитесь, что сайт включён, домен привязан к нужному внешнему IP и Nginx/Apache слушает публичный порт. Сравните server_name, ssl и upstream, не перенаправляйте внешний трафик на секретный административный порт.
- Проверьте сетевой экран на двух уровняхПосмотрите правила firewall ОС и облачного провайдера. Разрешайте только необходимый 80/443 для публичного сайта; административные и внутренние порты ограничивайте доверенными адресами/VPN. Не применяйте flush к правилам firewall.
- Повторите тест с внешней сетиС другого подключения проверьте HTTP и HTTPS, затем внутренний URL. Если соединение есть, но приходит чужой сайт — вернитесь к SNI/VirtualHost; если timeout — исследуйте маршрутизацию и firewall. При ошибке в новой настройке верните прежнюю публикацию.
#Проверка результата
Публичный домен отвечает ожидаемым сайтом по HTTPS с внешней сети, при этом внутренние служебные порты не доступны из интернета.
#Если проблема осталась
Если TCP есть, но HTTP 404/502, ищите ошибку виртуального хоста и upstream; если нет TCP, исследуйте сетевые ограничения и DNS отдельно.
#Безопасный откат
Если после изменения ошибка усилилась, верните сохранённое значение только изменённого параметра и повторно проверьте конфигурацию используемого веб-сервера до применения. Не возвращайте всю базу или весь сервер из резервной копии, если достаточно откатить одну настройку. При отсутствии доступа к нужному уровню обратитесь к администратору с точными временем, адресом, кодом ответа и обезличенными фрагментами журналов.