·3 сценария
Диагностические границы от URL до application result: не смешивать name, path, port, trust и semantics.
Эта диаграмма не повторяет request path, а превращает его в диагностический контракт. Проверка идёт слева направо и каждый этап отвечает только на один класс вопросов. Так команда перестаёт называть «сетью» всё от NXDOMAIN до exception в route handler.
Главный артефакт — first failing boundary: первая граница, для которой есть воспроизводимый negative result после подтверждённых prerequisites. Это сильнее списка случайных команд, потому что у вывода есть source host, timestamp и связь с конкретным request.
До запуска сформулируйте ожидаемый первый failure. Затем запишите exact command, host и time, чтобы результат можно было воспроизвести. Если ожидался TCP refusal, но получен TLS alert, hypothesis уже опровергнута: transport прошёл дальше, чем вы думали.
Для HTTP 503 сохраните status, response fields, body excerpt без sensitive data и request id. Сопоставьте его с edge и origin logs. Без этого 503 доказывает только наличие HTTP response, а не виновника.
В учебной diagnostic CLI держите отдельные exit codes или структурированные results для name resolution, connect и application protocol. Не печатайте один «connection failed» для всех веток. Сразу сохраняйте WSAGetLastError(), закрывайте только созданные sockets и продолжайте следующий addrinfo, если policy это допускает.
TLS boundary потребует отдельной библиотеки или системного API; Winsock даёт transport bytes. Это хорошая архитектурная граница: socket layer ничего не знает о hostname validation, а HTTP parser ничего не должен получать до успешной TLS validation.
Введите числа или выберите пресет