![\"Матрица](\"/assets/editorial/2027/http-tls-guide-2027-symptom-boundary-matrix.svg\")
В браузере одна красная страница, в логе клиента другая строка, а инженер уже меняет таймаут или отключает проверку сертификата. Такой ремонт часто начинается раньше факта: запрос мог остановиться на DNS, TCP или TLS и не дойти до HTTP. В обратной ситуации сертификат проверен, но приложение или proxy вернули 404, и поиски проблемы в TLS только уводят в сторону.
У запроса есть наблюдаемая последовательность: имя превращается в адрес, TCP принимает соединение, TLS проверяет защищённый канал и identity сервера, затем HTTP передаёт метод, цель и поля. Диагностика становится воспроизводимой, если на каждой границе задать свой вопрос, записать факт и не переносить вывод на следующий уровень. Эта схема не обещает мгновенно назвать виновника; она сужает место поиска и подсказывает следующий безопасный тест.
Начните с URI, например https://api.example.test/orders. Из него клиент получает схему, имя, порт и путь. DNS отвечает, какой адрес связан с именем. TCP отвечает, удалось ли открыть соединение с адресом и портом. Для HTTPS поверх TCP запускается TLS. Только после успешного TLS клиент отправляет HTTP-сообщение и получает статус, поля и тело.
Порядок важен не как учебная условность, а как ограничение доказательств. Если имя не разрешилось, вы ещё не проверяли порт. Если TCP не установлен, у приложения нет основания считать запрос полученным. Если TLS остановился на проверке identity, HTTP-заголовки и статус не объясняют отказ. Если статус 404 уже прочитан, TLS-обмен прошёл для этого соединения, но это ещё не доказательство, что ответ сформировал нужный origin.
| Граница | Наблюдение | Допустимый вывод | Чего пока нет |
|---|---|---|---|
| DNS | Получен A или AAAA-ответ | Имя разрешилось в один из адресов | Доступность порта и соответствие сертификата |
| TCP | Соединение установлено | Адрес принял соединение на выбранном порту | Успешная проверка TLS и HTTP-маршрут |
| TLS | Клиент принял защищённый канал | Проверки identity и доверия прошли для этого клиента | Нужный handler получил запрос |
| HTTP | Получены статус и поля | HTTP-обмен состоялся | Тело создал origin, а не cache или proxy |
| Приложение | Доверенный лог связал request id с handler | Известен компонент, обработавший вход | Так же ли настроены другие адреса и регионы |
Доверенный лог здесь важнее знакомого заголовка. Клиент может получить Server: familiar-product или X-Request-Id: local-001, но оба поля могли добавить или изменить по пути. Доказательство источника появляется, когда компонент под вашим контролем создал идентификатор и записал его вместе со временем, маршрутом и результатом.
Ошибка до HTTP-статуса ограничивает поиск транспортом. Сообщение о несовпадении имени сертификата требует проверить hostname и сертификат; оно не доказывает, что порт недоступен. Отказ TCP требует проверить маршрут, firewall, listener или балансировщик; он не говорит, какой HTTP-путь должен существовать. Таймаут без раздельных фаз оставляет место остановки неизвестным — не подставляйте туда удобную версию.
HTTP-ошибка уже принадлежит сообщению, которое кто-то сформировал. 404 Not Found означает, что получен HTTP-ответ с таким статусом, но не называет внутренний маршрут и не доказывает origin. 503 Service Unavailable сообщает о недоступности для данного отвечающего компонента; это может быть proxy, gateway или приложение. Ищите request id и запись того слоя, который действительно отправил ответ клиенту.
| Симптом | Гипотеза с ограниченной уверенностью | Первый тест | Не делать сразу |
|---|---|---|---|
| Нет статуса, ошибка сертификата | Не прошла проверка имени, цепочки или срока | Сверить hostname, SAN, trust store и срок действия | Не добавлять Host и не включать --insecure постоянно |
| Имя разрешилось, connect отклонён | Порт, маршрут или listener не принимает соединение | Сохранить адрес, порт и тип TCP-ошибки | Не проверять URL и бизнес-логику как первопричину |
TLS успешен, получен 404 | Путь, метод, authority или версия маршрута не совпали | Сверить запрос с логом входного proxy и известным endpoint | Не перевыпускать сертификат без нового факта |
Получен 503 | Отвечающий компонент не обслуживает запрос или не дождался upstream | Сопоставить слой, время ответа, Via и upstream-лог | Не увеличивать timeout и не повторять запись вслепую |
| Повтор даёт другой ответ | Кэш, балансировка, редирект или меняющееся состояние | Сравнить адрес, Age, ETag, Cache-Control и время | Не объединять ответы разных попыток в одну причину |
Для HTTPS недостаточно сказать «сертификат действующий». Клиент строит reference identity из имени или IP в URI и сопоставляет её с именами в сертификате. Затем он проверяет цепочку к доверенному anchor и период действия. Эти проверки отвечают на разные вопросы: сертификат может быть выдан правильным центром, но не для этого имени; имя может совпасть, но цепочка не доверена локальному клиенту; оба условия могут пройти, а срок — закончиться.
Подключение к IP вместо имени часто меняет проверяемую identity. Если сертификат выпущен для DNS-имени, сам факт, что IP указывает на тот же сервер, не делает IP подходящим именем. HTTP-поле Host не исправляет ошибку задним числом: оно появляется на уровне HTTP, после установления TLS. В HTTP/2 и HTTP/3 роль имени и порта в запросе обычно представляет :authority; при диагностике учитывайте фактическую версию протокола.
Флаг --insecure или его аналог может быть полезен в коротком разрешённом эксперименте: он показывает, что удалённая сторона способна отправить данные без обычной проверки identity. Но такой ответ не доказывает безопасность канала и не является исправлением. Результат эксперимента нужно явно пометить как полученный с отключённой проверкой и повторить обычным клиентом после исправления доверия.
HTTP-маршрут выбирается с учётом цели запроса. В HTTP/1.1 это видно через Host, а в HTTP/2 и HTTP/3 — через :authority. Один адрес может обслуживать несколько имён, поэтому несоответствие authority, пути или метода способно привести к 404 при полностью рабочем TLS. Уточняйте, какой компонент принимал соединение и какое значение он использовал для маршрутизации.
Посредник может завершить запрос сам, передать его дальше или вернуть результат из кэша. Поле Via по стандарту помогает увидеть промежуточные протоколы и получателей, но оно не является криптографической подписью тела. Age и валидаторы вроде ETag помогают заметить кэширование, а Cache-Control описывает правила хранения и повторного использования. Это признаки цепочки, а не самостоятельное доказательство конкретного origin.
Для расследования сохраняйте метод, нормализованный путь, authority, порт, момент, длительность, статус, размер тела и безопасный request id. Секреты и персональные данные в такой записи не нужны: удалите Authorization, cookie и чувствительные query-параметры. Если доступен только внешний ответ, напишите «источник не установлен». Такая формулировка полезнее уверенного, но неподтверждённого назначения владельца.
Пример запускается локально и намеренно не моделирует TLS. Он показывает, что статус относится к HTTP-маршруту, а вручную заданный request id не подтверждает доверенное происхождение. Сохраните код в check-http.mjs и запустите на Node.js с поддержкой встроенного fetch.
import { createServer } from 'node:http';\n\nconst server = createServer((request, response) => {\n const knownRoute = request.method === 'GET' && request.url === '/health';\n response.writeHead(knownRoute ? 200 : 404, {\n 'content-type': 'application/json; charset=utf-8',\n 'x-request-id': 'local-001',\n });\n response.end(JSON.stringify({\n method: request.method,\n path: request.url,\n route: knownRoute ? 'health' : 'missing',\n }));\n});\n\nserver.listen(0, '127.0.0.1', async () => {\n const { port } = server.address();\n for (const path of ['/health', '/missing']) {\n const response = await fetch('http://127.0.0.1:' + port + path);\n console.log(response.status, await response.json());\n }\n server.close();\n});Ожидаемый результат — 200 для GET /health и 404 для GET /missing. В обоих ответах будет local-001, потому что пример присваивает его сервером. Это воспроизводит локальный HTTP-контракт, но не доказывает, что аналогичное поле в production создано доверенным входным компонентом.
Отрицательный тест: замените путь на /health?token=demo. Сервер вернёт 404, потому что демонстрационный контракт сравнивает полный URL. Это не универсальное правило маршрутизации, а специально видимое условие примера. После теста не переносите его буквально в приложение: реальный роутер может отдельно разбирать path и query. Ценность эксперимента в том, что изменение одного условия меняет наблюдаемый результат.
Via, Age, ETag, Cache-Control и длительность, если подозреваете intermediary или cache. Сравните холодный и повторный запрос.POST сначала проверьте идемпотентность или ключ дедупликации; ответ 503 сам по себе не делает повтор безопасным.Модель описывает порядок доказательств, а не конкретную реализацию сети. Она не заменяет packet capture, распределённую трассировку, настройки CDN, корпоративного proxy, DNS-кэш, региональную балансировку или наблюдение внутри закрытого сегмента. У клиента могут быть скрыты отдельные фазы, поэтому итоговый timeout нельзя разложить на DNS, TCP и TLS без дополнительного измерения.
Локальный сервер не подтверждает работу реального origin, сертификата, балансировщика или кэша. Поле Via может быть скрыто политикой, а request id от внешней стороны может отсутствовать или быть перезаписан. Сопоставляйте только те записи, которым доверяете в своей цепочке. Нельзя переносить учебный порт, hostname, заголовок и ожидаемый статус в production без отдельного контракта.
Для операции, меняющей заказ, деньги, подписку или иной ресурс, сетевой сбой оставляет результат неопределённым: сервер мог применить действие и потерять ответ. RFC различает идемпотентные методы и остальные, но бизнес-операция может иметь дополнительные побочные эффекты. Без ключа операции, проверки состояния или явного правила сервиса безопаснее остановить автоматический повтор и передать решение владельцу контракта.
Диагностика готова, если для одного endpoint есть две очищенные записи: успешная и ошибочная. В каждой указаны время, hostname, порт, метод, безопасный путь, этап, статус или текст ошибки, длительность и ожидаемый следующий тест. Для HTTPS отдельно зафиксированы identity, цепочка и срок; для HTTP — authority, маршрут, источник ответа и признаки кэша, если они доступны.
Исправление считается подтверждённым после изменения одного условия и повторного запуска с обычной проверкой сертификата. Ожидаемый результат должен быть сформулирован заранее: например, известный маршрут возвращает 200, отсутствующий — 404, а ошибка до TLS не получает выдуманный HTTP-статус. Если логи не связывают ответ с доверенным компонентом, честный результат проверки — «источник не установлен», а не имя предполагаемого сервиса.
https, проверка identity, Host и :authority, посредники, кэш, статусы и свойства методов.