Исходная ситуация:
systemctl status nginx → active (running) ss -lntp → LISTEN 0 511 0.0.0.0:443 curl -k https://localhost/ → HTTP/1.1 200 OK
На самом сервере всё выглядит нормально. Но с рабочей станции:
https://service.example.ru
не открывается. Первый соблазнительный вывод: проблема где-то в сети. Возможно. Но пока мы знаем только одно: локальная проверка приложения успешна, а пользовательский сценарий — нет. Теперь нужно определить, на каком участке перестаёт проходить запрос.
1. Что уже подтверждено
systemctl status показывает:
nginx → active (running)
То есть systemd считает сервис запущенным.
ss показывает:
0.0.0.0:443 → LISTEN
Значит, на сервере существует TCP-сокет, ожидающий соединения на порту 443.
curl localhost возвращает:
HTTP 200
Это уже более сильное подтверждение: локально веб-сервис способен принять запрос и вернуть корректный HTTP-ответ. Но из этого ещё не следует:
сервис работает локально
≠
сервис доступен пользователю
2. Разделяем путь запроса на участки
Пользовательский запрос проходит не один тест, а целую цепочку:
пользователь
↓
DNS
↓
маршрутизация
↓
межсетевые экраны / ACL
↓
NAT / балансировщик / обратный прокси
↓
сервер
↓
TCP socket
↓
nginx
↓
приложение
Если локальный curl успешен, мы проверили только последнюю часть этой цепочки.
Проблема может находиться выше.
3. Начинаем с DNS
С рабочей станции проверяем:
nslookup service.example.ru
или:
dig service.example.ru
Ожидаем нужный IP-адрес. Например:
service.example.ru → 192.0.2.50
Если DNS возвращает старый или вообще другой адрес, дальнейшая диагностика сервера может быть бессмысленной. Получаем первое разделение:
имя разрешается неправильно
↓
проблема DNS
имя разрешается правильно
↓
идём дальше
4. Проверяем TCP-доступность
С той же рабочей станции:
nc -vz service.example.ru 443
или другим доступным способом проверяем установление TCP-соединения. Если соединение не устанавливается, область поиска уже значительно уже:
клиент ↓ сеть ↓ порт 443 ↓ сервер
На этом этапе nginx и само приложение могут быть совершенно исправны.
5. Локальный firewall
На сервере проверяем действующие правила. Например:
firewall-cmd --list-all
или:
nft list ruleset
Нас интересует не просто наличие правила с 443.
Важно понять:
— в какой зоне находится интерфейс;
— к какой сети относится клиент;
— нет ли ограничений по source;
— действительно ли правило применяется к нужному трафику.
Типовая ошибка выглядит так:
443 разрешён
но:
интерфейс находится в другой firewalld zone
Формально правило существует. Фактически нужный трафик под него не попадает.
6. Если локальный firewall пропускает — идём наружу
Между клиентом и сервером могут находиться:
- — корпоративный межсетевой экран;
- — ACL на маршрутизаторе;
- — security group в облаке;
- — VPN ACL;
- — NAT;
- — балансировщик;
- — reverse proxy.
Поэтому ситуация:
server firewall → ACCEPT
ещё не означает:
client → server → reachable
Нужно определить, где именно проходит граница доступности.
7. Проверяем маршрут
На клиенте полезно посмотреть маршрут до назначения. Например:
traceroute service.example.ru
или соответствующим инструментом для используемой ОС. Но и здесь важно не переоценивать результат. Отсутствие ответа от промежуточного узла ещё не означает, что именно он блокирует рабочий трафик: ICMP может фильтроваться отдельно. Поэтому маршрут — это дополнительное подтверждение, а не готовый вывод.
8. Очень полезная проверка — посмотреть, доходит ли трафик до сервера
На сервере:
tcpdump -ni any tcp port 443
И одновременно пробуем подключиться с рабочей станции. Возможны два принципиально разных результата. Вариант A
На сервере вообще нет входящих пакетов от клиента. Тогда проблема находится до сервера:
routing ACL firewall NAT
Вариант B
SYN-пакеты приходят на сервер. Значит, клиентский трафик уже преодолел значительную часть сетевого пути. Теперь нужно смотреть: что сервер делает с этим соединением?