Автоматизация проверки доменов в зоне .ru позволяет сократить время подбора имени бренда с 4-5 часов ручного поиска до 15-20 секунд работы скрипта. При массовом сканировании (от 1000 запросов) использование стандартных методов DNS-запросов приводит к бану IP-адреса регистратора в 80% случаев.
Методы проверки: WHOIS против DNS-запросов
Для проверки доступности домена .ru используют два основных пути: запрос к WHOIS-серверу (whois.tilda.ru или аналоги) и проверку DNS-записей (функция checkdns). WHOIS дает 100% точность, но имеет жесткие лимиты: при частоте более 2-3 запросов в секунду с одного IP сервер начнет отдавать ошибку 429 или временно заблокирует доступ на срок от 1 до 24 часов.
DNS-запрос работает быстрее (отклик 10-50 мс против 200-500 мс у WHOIS), но он неточен: если домен зарегистрирован, но для него не настроены NS-записи, скрипт ошибочно пометит его как «свободный». В практике веб-мастеров такая погрешность составляет до 15% от общего объема базы.
Экспертный вывод: для точечного подбора 1-10 имен используйте WHOIS, для первичного фильтрации списков из 10 000+ вариантов — DNS-запросы с последующей верификацией через API регистратора.
Реализация на PHP: архитектурные нюансы
Простой однопоточный скрипт на PHP обрабатывает около 2-5 доменов в секунду. Чтобы увеличить скорость до 50-100 проверок в секунду, необходимо внедрять многопоточность через расширение curl_multi или использовать библиотеку ReactPHP. Без этого проверка списка из 5000 доменов займет около 20 минут вместо 40 секунд.
Критическая ошибка новичков — отсутствие кэширования. Повторный запрос одного и того же домена в течение часа — это пустая трата ресурсов и риск бана. Внедрение Redis или простого файлового кэша снижает нагрузку на сеть на 30-40% при итеративном подборе вариантов имени.
Экспертный вывод: используйте curl_multi для параллельных запросов и обязательно внедряйте задержку (sleep) в 0.2-0.5 секунды между пачками запросов, чтобы имитировать поведение человека.
Обход ограничений и работа с прокси
При масштабировании до 10 000+ запросов в сутки одного IP недостаточно. Стоимость качественных резидентских прокси для таких целей варьируется от $3 до $15 за ГБ трафика. Использование дешевых дата-центр прокси (по $1-2 за пакет) неэффективно, так как их подсети часто занесены в черные списки WHOIS-серверов зоны .ru.
Кейс: при создании сервиса генерации имен для ниши гемблинга проверка 50 000 комбинаций через один сервер привела к блокировке IP через 12 минут работы. Решение — ротация пула из 50 прокси, что позволило завершить задачу за 45 минут без единого сбоя.
Экспертный вывод: для серьезного парсинга доменов инвестируйте в резидентские прокси с ротацией по каждому запросу — это единственный способ избежать блокировок при больших объемах.
API регистраторов как альтернатива самописному коду
Использование API (например, Reg.ru или Nic.ru) снимает проблему с прокси и блокировками, но переносит расходы в плоскость оплаты за запросы или ежемесячной подписки. Стоимость API-доступа может варьироваться от бесплатного (с лимитом 100-500 запросов в сутки) до платных тарифов, где стоимость одного запроса нивелируется объемом.
Сравнение: самописный скрипт на прокси обходится в $10-20/мес при неограниченном объеме, тогда как коммерческий API при высокой нагрузке может потребовать оплаты индивидуального тарифа. Однако API гарантирует актуальность данных в реальном времени, исключая задержку обновления WHOIS-баз, которая иногда достигает 15-30 минут.
Экспертный вывод: если ваша задача — разовый подбор имени, пишите скрипт. Если вы создаете коммерческий сервис мониторинга доменов, используйте API регистратора, чтобы избежать технических рисков и юридических претензий.
Вывод
Для разовых задач по подбору домена .ru оптимален самописный PHP-скрипт на базе curl_multi с использованием резидентских прокси и кэшированием в Redis. Избегайте простых DNS-проверок для финального решения — они врут в 15% случаев. Если же вы строите бизнес-инструмент, не тратьте время на борьбу с банами WHOIS и сразу интегрируйте API официального регистратора, даже если это потребует дополнительных затрат на лицензии. Начинайте с минимального MVP на DNS, затем переходите к WHOIS, и только при масштабировании — к API.