#Симптом и границы применимости
Apache нормально отвечает на локальный curl, но домен не открывается из интернета. Локальная проверка не проверяет DNS, внешние сетевые правила, маршрутизатор, NAT, балансировщик и доступность IPv4/IPv6; настройку Listen нужно сверить с архитектурой.
#Возможные причины и как их отличить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Слушает только loopbackПри наличии Nginx-прокси внутренний Apache может намеренно слушать только loopback. | ss показывает 127.0.0.1:80 или [::1]:80 | Установить, нужен ли прямой внешний доступ |
| Внешний порт заблокированОткрытие на уровне Apache не разрешает входящий трафик в сети. | Локальный запрос успешен, внешний TCP-тест не соединяется | Проверить облачный firewall, NAT и сетевой экран Linux |
| DNS ведёт к другому узлуЛокальный тест по 127.0.0.1 не проверяет маршрутизацию домена. | A/AAAA не совпадают с опубликованным IP | Сверить DNS с публичным адресом сервера/балансировщика |
#Пошаговая диагностика и исправление
- Разделите ошибку соединения и HTTP-кодОткройте сайт с мобильной сети, не подключённой к Wi-Fi сервера. Ошибка соединения, тайм-аут, 403 и неверный сертификат требуют разных проверок. Зафиксируйте время, домен, порт и семейство адресов. Не меняйте правила безопасности до определения точки отказа.
- Посмотрите, что реально слушает серверПо SSH проверьте TCP-сокеты и сопоставьте PID с Apache/Nginx. Состояние LISTEN на 127.0.0.1 означает локальный приём; 0.0.0.0 — все IPv4-адреса (если политики не препятствуют). Если Apache стоит за Nginx, внешние 80/443 обязан слушать именно внешний компонент.
- Команда для Linux; в контейнере сетевые пространства имён могут различатьсяLinux · Терминал (Bash)КомандаНужен sudoКоманда для Linux; в контейнере сетевые пространства имён могут различаться.
sudo ss -lntp | grep -E ":(80|443|8080)\b"
- Проверьте активные Listen и VirtualHostВыполните синтаксический тест и вывод виртуальных хостов, затем выясните, должен ли Apache принимать прямые внешние подключения. Не меняйте Listen localhost на публичный IP, если панель использует Apache за Nginx — это может открыть обход защиты.
- Проверки только чтение; Debian/UbuntuLinux · Терминал (Bash)КомандаНужен sudoПроверки только чтение; Debian/Ubuntu.
sudo apache2ctl configtest; sudo apache2ctl -S
- Проверьте публичные адреса и DNSНа внешнем устройстве посмотрите записи A и AAAA, сравните с адресом балансировщика либо внешним адресом сервера, указанным в панели. Если AAAA старый, посетители IPv6 могут попадать на другой хост.
- Команды для клиентского терминала с dig; замените доменLinux · Терминал (Bash)КомандаКоманды для клиентского терминала с dig; замените домен.
dig +short A example.com; dig +short AAAA example.com
- Проверьте сетевые правила без отключения экранаНа сервере прочитайте nftables, в панели провайдера — входящие правила нужного IP/порта. Если есть домашний маршрутизатор — проверьте перенаправление портов и наличие публичного адреса; при CGNAT проброс может быть невозможен. Не открывайте внутренний 8080, если он должен быть доступен только Nginx.
- Только чтениеLinux · Терминал (Bash)КомандаНужен sudoТолько чтение. Открывайте только необходимые внешние порты по принятой схеме.
sudo nft list ruleset
- Проверьте результат снаружиПосле адресной корректировки повторите запрос с независимого подключения и сравните код, сертификат и IP назначения. При изменении конфигурации Apache выполните configtest перед reload; если изменение только в DNS, дождитесь обновления кэша записей, не перезапуская Apache.
#Как проверить результат
С внешней сети по домену доступен ожидаемый виртуальный хост, сертификат соответствует имени, IPv4/IPv6 ведут на нужные узлы; служебный внутренний порт не открыт наружу без необходимости.
#Если проблема не устранена
Если локальные и внешние проверки расходятся, отследите путь DNS → балансировщик/CDN → межсетевой экран → Apache. Попросите провайдера проверить маршрутизацию при отсутствии публичного адреса.