Вступление
Вы когда-нибудь подключались к Wi-Fi в кафе или аэропорту, и телефон сам открывал браузер со страницей входа? Или наоборот — подключались, а интернета нет, но и страница не появляется?
За этим стоит технология Captive Portal. А ключевую роль в её обнаружении играют несколько специальных URL, которые «зашиты» в каждую операционную систему. В этой статье разберем, как они работают, какие именно адреса используют iPhone, Android и Windows, и почему HTTPS иногда всё ломает.
Как это работает: «приманка» для сети
Когда ваш телефон или ноутбук подключается к новой Wi-Fi, он не показывает вам страницу входа сразу. Сначала он делает незаметный фоновый запрос по одному из зарезервированных адресов (например, http://captive.apple.com/hotspot-detect.html).
- Идеальный сценарий: Сервер возвращает код 204 No Content (или короткую строку вроде
Success). Устройство думает: «Интернет есть, портала нет». Браузер не открывается. - Сценарий с порталом: Роутер перехватывает запрос и вместо кода 204 возвращает 302 Redirect (перенаправление) на страницу авторизации. Устройство понимает: «Ага, трафик перехвачен! Нужно открыть браузер и показать эту страницу пользователю».
📱 Секретные URL от производителей (и ваш список)
Теперь — главное. Вот какие конкретно адреса «зашиты» в самые популярные устройства. Ваш список оказался абсолютно верным, я лишь добавлю контекст.
| URL | Владелец | Где используется | Что ожидает устройство |
|---|---|---|---|
http://captive.apple.com/hotspot-detect.html | Apple | iPhone, iPad, Mac | Текст Success (код 200) |
http://connectivitycheck.gstatic.com/generate_204 | Android, Chromebook | Код 204 | |
http://www.google.com/generate_204 | Windows, старые версии Chrome, скрипты | Код 204 | |
http://cp.cloudflare.com/generate_204 | Cloudflare | Альтернативный URL, некоторые роутеры и приложения | Код 204 |
Почему именно HTTP, а не HTTPS? Это ключевой момент. Для проверки используется незашифрованный HTTP. Почему? Представьте: портал пытается подменить ответ для HTTPS-запроса. Это потребовало бы поддельного сертификата, и браузер выдал бы страшную ошибку безопасности, а не окно входа. Поэтому проверка всегда идет по HTTP, а окно портала открывается по любому протоколу.
🖥 А что насчет других систем?
Ваш список покрывает 90% мобильных устройств. Но есть и другие:
- Microsoft Windows:
http://www.msftconnecttest.com/connecttest.txt - Mozilla Firefox:
http://detectportal.firefox.com/success.txt - Fedora / Linux:
http://fedoraproject.org/static/hotspot.txt - Ubuntu / Linux:
http://connectivity-check.ubuntu.com
🔧 Практическое применение (для администраторов)
Знание этих URL решает две реальные задачи:
- Диагностика проблем. Если вы подозреваете, что сеть перехватывает трафик там, где не должна, попробуйте в браузере открыть
http://captive.apple.com/hotspot-detect.html. В нормальной сети вы увидитеSuccess. Если видите что-то другое (или перебросило на другую страницу) — значит, портал активен. - Настройка белых списков (whitelist). Если вы управляете корпоративным роутером или шлюзом с каптивным порталом, обязательно добавьте все эти домены в исключения (bypass). Устройства должны получать чистый ответ 204 без перехвата. Иначе они «зациклятся»: телефон будет думать, что портал не отпускает, и не даст пользователю нормальный доступ.
💡 Главный вывод
Эти маленькие URL — не просто технические детали. Это «язык», на котором ваше устройство договаривается с сетью: «Ты портал или нет?». Понимая этот механизм, вы сможете легче отлаживать проблемы с Wi-Fi, настраивать гостевые сети и даже «обманывать» систему в некоторых публичных сетях, подставляя свои заглушки.
А теперь проверьте себя: откройте в браузере по очереди каждый из этих адресов. Что вы видите? Если Success или пустую страницу — ваш интернет работает чисто.
P.S. Если у вас есть свой сервер, вы можете разместить файл generate_204 или hotspot-detect.html и использовать его в качестве пользовательского теста подключения. Главное правило — он должен отвечать быстро и без редиректов.
