Адреса, порты и путь HTTP-запроса

Оглавление серии

В прошлом уроке служба связала конфигурацию с процессом. Теперь рассмотрим путь запроса. Пользователь обращается к имени сайта, система получает адрес, соединение достигает выбранного порта, а приложение формирует HTTP-ответ. Проблема на любом этапе может выглядеть одинаково: «страница не открывается». Для диагностики разделим этапы и выберем отдельное наблюдение для каждого.

DeskQueue из серверного курса слушает IPv4-адрес 127.0.0.1 и порт 3000. Это локальный адрес самой машины. Учебное имя deskqueue.example.com служит обозначением в документации и не является настроенным публичным доменом лаборатории. Если вы не создали собственную DNS-запись и внешний прокси, нельзя ожидать доступа из интернета только потому, что процесс уже запущен.

Учебная схема показывает четыре разных места наблюдения. Она помогает выбрать следующий вопрос, когда один из этапов уже подтверждён.

Интерфейс не является приложением

Сначала прочитайте адреса интерфейсов и маршруты. Эти команды показывают настройки, не изменяя сеть. Важно выполнить их внутри той машины, где должна работать служба, а не на компьютере, с которого открыт терминал.

ip -br address
ip route show

В кратком выводе ожидается loopback-интерфейс и, в зависимости от стенда, один или несколько сетевых интерфейсов. Конкретные имена отличаются. Не привязывайте дальнейшие действия к найденному в чужой статье eth0. Маршрут показывает, как выбирается направление для адреса назначения; он не говорит, что на конечной машине есть нужная программа.

Параметры чтения описаны в справке ip. У этой же команды есть возможности изменения адресов и маршрутов, но они не нужны для нашего первого наблюдения. Если локальное API не слушает порт, изменение маршрута не заставит его появиться. Двигайтесь от подтверждённого факта к следующему вопросу, сохраняя уровень проблемы.

Кто слушает порт

Команда ss позволяет выбрать слушающие TCP-сокеты и ограничить их портом. Числовой вывод уменьшает неоднозначность имён служб. Сведения о процессе могут быть недоступны обычному пользователю для чужой учётной записи, поэтому отсутствие имени процесса не равно отсутствию сокета.

ss -ltnp 'sport = :3000'

Для подготовленного и запущенного DeskQueue ожидается локальный адрес 127.0.0.1:3000. Если видите 0.0.0.0:3000, программа использует другой договор привязки. Если строки нет, сначала проверьте состояние службы и порт из её конфигурации. Возможно, приложение ещё не запущено, завершилось или работает в другом сетевом пространстве. Поиск в текущей машине не показывает автоматически сокеты соседнего контейнера.

В справке ss отдельно описаны выбор слушающих сокетов, TCP и фильтры. В нашем вопросе важны адрес и порт, а не все соединения системы. Срез легче сопоставить со службой и передать коллеге. Полный список клиентских соединений может добавить много лишнего, не объясняя отсутствие нужного слушателя.

Приложение отвечает на HTTP

Наличие слушателя подтверждает более узкий факт, чем успешная работа API. Теперь обратимся к двум известным адресам из самой Linux-машины. Ограничим ожидание, чтобы отсутствие ответа не удерживало наблюдение бесконечно.

curl -sS --max-time 3 -i http://127.0.0.1:3000/health
curl -sS --max-time 3 -i http://127.0.0.1:3000/ready

При готовом серверном примере первый ответ должен содержать имя DeskQueue и статус процесса. Второй проверяет готовность, включая запрос к базе. Если он возвращает 503, TCP и HTTP уже работают: теперь вопрос относится к приложению или его зависимости. Не называйте такой ответ сетевой недоступностью. Это различие направляет чтение журнала в нужную сторону.

Отказ соединения, превышение времени и HTTP-статус — разные результаты. При отказе может отсутствовать слушатель на адресе. При ожидании возможны другие причины, включая задержку ответа. HTTP-ошибка уже означает получение сообщения от какого-то участника пути. Сохраняйте заголовки и статус, а не только фразу «curl не работает», чтобы следующий читатель мог восстановить уровень наблюдения.

Имя и системный способ разрешения

Когда используете собственный домен, отдельно рассмотрите его разрешение. dig обращается к DNS, а getent hosts использует настроенный механизм разрешения имён системы. Результаты могут различаться, например, из-за записи в /etc/hosts. Для учебного имени отсутствие записи допустимо и не является доказательством неисправности нашей службы.

getent hosts deskqueue.example.com
dig deskqueue.example.com A
dig deskqueue.example.com AAAA

Команда dig может отсутствовать в минимальной установке; это вопрос комплекта инструментов. Не подменяйте её вывод придуманным адресом. Также учитывайте обе семьи адресов. Браузер может выбрать IPv6, тогда как вы вручную рассмотрели только IPv4. Для своего стенда записывайте фактически полученные записи и то, к какому адресу относился запрос.

DNS не содержит номер внутреннего порта приложения. Для обычного HTTP-перехода клиент использует договор протокола и указанный URL, а внешний сервер или прокси может направить запрос к локальному порту 3000. Поэтому правильная A-запись не гарантирует наличие этой связи. Разделите проверку имени, публичного слушателя и внутреннего API, чтобы не пытаться исправить один уровень настройкой другого.

Видимость процессов и контейнеров

lsof может дополнить наблюдение открытых файлов и сокетов конкретного процесса. Например, выбор TCP-порта помогает сопоставить ресурс с PID. Однако инструмент может быть не установлен, а доступ ограничен. В этой лаборатории ss и состояние службы являются базовыми источниками; дополнительный инструмент должен отвечать на оставшийся вопрос, а не дублировать длинный список ради объёма отчёта.

Контейнерная сеть добавляет отдельный контекст: localhost внутри контейнера относится к нему самому. Запрос с хоста к его собственному 127.0.0.1:3000 не обязан попадать в контейнер без опубликованного порта. Сравнивайте, где выполнялась каждая команда. Курс Docker отдельно объясняет публикацию портов; здесь используем обычную машину, чтобы сначала понять уровни.

В evidence/network.md свяжите службу, адрес слушателя, HTTP-статусы и имя, если оно настроено. Результат главы — диагностическая цепочка с ясными границами. Следующий шаг изучает ситуацию, когда приложение доступно, но отвечает медленно: рассмотрим процессы, память, нагрузку и временные наблюдения без преждевременного вывода о причине.