🌐 Самый раздражающий тип сетевой проблемы — это не когда “всё умерло”, а когда **что-то работает наполовину**.
Сайт в браузере открывается. Главная грузится. Иногда даже логин проходит. Но приложение при этом не подключается, API отдаёт ошибки, картинки не тянутся, push не приходят, а часть функций просто молча отваливается.
Именно в таких случаях у людей обычно начинается хаос в выводах:
• “значит сайт не заблокирован”;
• “значит приложение кривое”;
• “значит это просто временный глюк”;
• “значит VPN плохой”.
На практике всё сложнее. Частичная недоступность — это как раз один из самых типичных сценариев, когда **ломается не весь сервис целиком, а отдельный слой**: DNS, API-домен, CDN, транспорт, TLS, HTTP/3, конкретный протокол или часть маршрута.
Главная мысль здесь простая:
**“сайт открывается” не равно “сервис полностью доступен”**. 🔍
## Почему так вообще бывает
Когда обычный пользователь думает о сервисе, он видит одну сущность:
• вот сайт,
• вот приложение,
• вот сервис.
Но технически это почти всегда набор разных компонентов:
• основной домен;
• API-домен;
• CDN для статики;
• отдельные хосты под медиа;
• auth endpoints;
• websocket endpoint;
• push / telemetry / дополнительные backend-сервисы.
И они могут вести себя **по-разному**.
То есть браузер может спокойно открыть:
example.com
но приложение при этом пытаться ходить в:
• api.example.com
• cdn.example.com
• auth.example.com
• static.examplecdn.net
И если ломается не главный сайт, а один из этих компонентов, внешне ты получаешь очень странную картину:
• “сайт работает”,
• “приложение нет”.
## Где чаще всего ломается
### 1. DNS
Самый банальный сценарий — у тебя нормально открывается один домен, но другой резолвится с ошибкой, криво или нестабильно.
Например:
• главная страница живёт на одном имени;
• API уходит на другом;
• приложение использует третий домен для auth или media.
В итоге сайт открывается, а приложение выглядит “сломавшимся без причины”.
### 2. API endpoint
Очень частая история: фронт живой, а backend API частично недоступен.
Снаружи это выглядит так:
• сайт прогрузился;
• но список не подгрузился;
• кнопка ничего не делает;
• логин не проходит;
• приложение зависает на экране загрузки.
И тут ошибка не в “сайте”, а в том, что **API отдельно не отвечает**.
### 3. CDN или медиа-хост
Главная HTML-страница может открываться, но:
• JS не догружается,
• изображения не тянутся,
• видео не стартует,
• CSS или bundle-файлы бьются по таймауту.
И пользователь говорит:
“сайт открывается, но пользоваться им невозможно”.
Формально это правда: домен живой, а сервис по сути сломан.
### 4. Разный протокол
Иногда проблема сидит вообще не в домене, а в том, **как именно идёт трафик**:
• HTTP/2 ок, а HTTP/3 ведёт себя странно;
• TCP работает, а QUIC деградирует;
• TLS поднимается, но приложение использует другой режим соединения;
• браузер и мобильное приложение ходят не одинаково.
### 5. Частичный маршрут или локальная фильтрация
Бывает и так:
• один маршрут до сервиса живой,
• другой деградирует;
• сайт попадает в “удачную” часть сети,
• а приложение стучится в другой endpoint и упирается в проблемы по пути.
Именно поэтому частичные блокировки и деградации так бесят: они не выглядят как честное “всё легло”.
## Почему браузер и приложение могут вести себя по-разному
Очень важно понимать:
**браузер и приложение — это не одно и то же с точки зрения сетевого поведения**.
Браузер:
• может использовать другой DNS-кэш;
• может работать через DoH;
• может кэшировать часть статики;
• может иначе обрабатывать ошибки;
• может открывать сайт даже если часть ресурсов умерла.
Приложение:
• часто жёстче завязано на API;
• хуже переживает таймауты;
• может ломаться из-за одного недоступного backend endpoint;
• часто менее “терпеливо” к проблемам с сертификатами, QUIC, websocket или auth.
Поэтому ситуация:
“в браузере открывается, в приложении нет”
вообще не редкость. Это не магия и не обязательно “приложение плохое”. Это просто значит, что они используют сервис **не одинаково**.
## Как разбирать такую проблему без гадания
Нормальный путь — разделять доступность по слоям.
### Шаг 1. Проверить DNS
Резолвятся ли:
• основной сайт,
• API-домен,
• CDN-домен,
• auth endpoint.
Если главный сайт живой, а API-домен уже даёт мусор — причина понятнее сразу.
### Шаг 2. Проверить TCP/TLS
Поднимается ли соединение до нужного хоста и порта вообще.
Потому что HTML в браузере мог открыться из кэша или по одному endpoint, а реальная проблема сидит на другом.
### Шаг 3. Проверить HTTP отдельно по каждому домену
Не “работает ли сервис вообще”, а:
• работает ли сайт,
• работает ли API,
• работает ли статика,
• работает ли auth.
### Шаг 4. Сравнить браузерный и приложенческий сценарий
Если сайт открывается, но приложение нет — надо смотреть, **куда именно ходит приложение**, а не делать вывод по главной странице.
## Когда это похоже именно на частичную блокировку
Признаки обычно такие:
• главный домен живой;
• часть поддоменов нестабильна;
• приложение страдает сильнее, чем браузер;
• через другой маршрут, VPN или прокси всё внезапно оживает;
• проблема повторяется не тотально, а кусками.
Это очень характерный паттерн: не “полный бан”, а **частичная деградация отдельных компонентов**.
## Почему это важно
Потому что без этой логики очень легко чинить не то.
Например:
• менять приложение, когда проблема в API-домене;
• ругать DNS, когда ломается маршрут до CDN;
• винить VPN, когда умирает один конкретный endpoint;
• говорить “сайт не заблокирован”, просто потому что открылась главная страница.
А это и есть главный самообман:
**сервис может быть доступен частично и при этом практически бесполезен для пользователя**.
## Итог
Если сайт открывается, а приложение нет — это ещё не парадокс и не повод делать быстрый вывод.
Чаще всего это значит, что ломается **не весь сервис целиком, а один из его компонентов**:
• DNS,
• API,
• CDN,
• auth,
• протокол,
• маршрут,
• конкретный тип трафика.
Именно поэтому в таких ситуациях нельзя проверять только главную страницу и говорить “ну всё же работает”.
Надо смотреть глубже: **какой именно слой жив, а какой уже разваливается**. 📡
Если тебе интересны такие практические разборы по сетевой диагностике, VPN, блокировкам и реальному устройству сервисов — подписывайся на мой Telegram-канал Pro IT:
https://t.me/pro_it_news