Представьте: вы написали клиент, который делает запросы к сайту, и всё работает. А потом внезапно сыплются ошибки, воркеры зависают, а сервер отвечает загадочным кодом 429. Знакомо? Тогда этот гайд для вас. Мы разберём, как построить HTTP-клиент, который не паникует при первой проблеме, а ведёт себя вежливо и устойчиво.

Введение: почему 429 - это не ошибка, а сигнал

Многие разработчики видят код 429 и думают: сломалось. На самом деле сервер говорит вам совершенно конкретную вещь: вы шлёте слишком много запросов, притормозите. Это не отказ и не блокировка навсегда. Это просьба сбавить темп. И если вы услышите её правильно, ваш клиент станет надёжным.

Что получит читатель в итоге

К концу этого руководства у вас будет готовый рабочий HTTP-клиент, который умеет несколько важных вещей. Он корректно обрабатывает код 429 и уважает заголовок Retry-After. Он использует экспоненциальный backoff с джиттером, чтобы не устраивать шторм повторов. Он ограничивает параллелизм, чтобы не топить целевой сервер. И он не зависает благодаря грамотным тайм-аутам.

Вы получите готовые фрагменты кода на трёх языках: Python (через библиотеку httpx и через urllib3 Retry), Node.js и Go. Каждый фрагмент вы сможете вставить в свой проект и адаптировать под задачу.

Для кого этот гайд

Гайд рассчитан на начинающих разработчиков, которые уже умеют делать простые HTTP-запросы, но пока не сталкивались с продакшн-нагрузкой. При этом здесь есть блоки для продвинутых: circuit breaker, метрики, управляемая деградация. Если вы пишете парсер, интеграцию с чужим API и]]>Wed, 29 Jul 2026 15:29:00 +0300https://www.proxeon.net/pages/dns-cherez-proksi-socks5-protiv-socks5h-udalyonnyi-rezolv-i-utechki.htmlDNS через прокси: socks5 против socks5h, удалённый резолв и утечки

Представьте картину. Вы подключили прокси нужного региона, проверили IP-адрес - всё верно, город и страна совпадают. Но целевой сайт упрямо показывает вам не тот контент, а система антифрода помечает сессию как подозрительную. Знакомо? Скорее всего, вы столкнулись с одним из самых коварных явлений в работе с прокси - утечкой DNS или неправильным путём резолва доменного имени.

Эта статья - исчерпывающее руководство по тому, как именно происходит преобразование доменного имени в IP-адрес, когда трафик идёт через прокси. Мы разберём, чем принципиально отличаются схемы socks5 и socks5h, кто и на каком этапе отправляет DNS-запрос, почему сайт иногда видит совсем не тот регион, который вы ожидали, и как настроить удалённый резолв в популярных клиентах и библиотеках. Тема узкая, но чертовски важная. Именно на резолве имён рушатся тысячи, казалось бы, правильно настроенных конфигураций.

Введение: почему прокси подключён, а сайт видит не тот регион

Давайте начнём с симптома, который приводит большинство читателей к этой теме. Вы настроили прокси. IP-адрес подменён корректно - это легко проверить на любом сервисе определения IP. И всё же что-то идёт не так: сайт отдаёт локализацию другой страны, CDN направляет вас на неожиданный узел, а иногда система безопасности целевого ресурса блокирует запрос без видимых причин.

Причина почти всегда одна и та же. Ваш HTTP или прикладной трафик действительно идёт через прокси, но DNS-запрос - тот самый запрос, который превращает имя вроде example.com в конкретный IP-адрес - уходит мимо прокси, напрямую с вашей машины. И этот запрос выдаёт вас с головой.<]]>Mon, 27 Jul 2026 13:40:00 +0300https://www.proxeon.net/pages/udp-cherez-socks5-komanda-udp-associate-pochemu-http-proksi-ne-umeet-udp-i-kak-proverit.htmlUDP через SOCKS5: команда UDP ASSOCIATE, почему HTTP-прокси не умеет UDP и как проверить

Знакомая ситуация: вы настроили прокси, браузер открывает сайты, парсер собирает данные, всё выглядит идеально. А потом вы запускаете видеозвонок, и собеседник вас не слышит. Или заходите в онлайн-игру, и матч не подключается. Или запускаете голосовой чат, и он молчит. Прокси ведь работает? Работает. Но что-то сломано на глубоком уровне, и понять это без знаний о транспорте практически невозможно.

Причина почти всегда одна и та же: ваш прокси не пропускает UDP-трафик. И это не поломка, а фундаментальное свойство. Одни типы прокси умеют работать с UDP по стандарту, другие не умеют в принципе. Разница между этими двумя мирами определяет, будет ли у вас работать реальное общение в интернете или только загрузка веб-страниц.

В этом руководстве мы разберём тему от самого фундамента до практических инструментов проверки. Вы узнаете, как устроена команда UDP ASSOCIATE в протоколе SOCKS5, почему HTTP-прокси через метод CONNECT не может передавать датаграммы физически, что именно ломается у пользователя без UDP и как самостоятельно, буквально за несколько минут, проверить любой прокси на реальную поддержку UDP. Мы будем говорить только о транспорте: без разбора выбора между типами прокси и без инструкций по настройке конкретных приложений.

Основы: TCP против UDP, датаграммы и уровень работы прокси

Чтобы понять, почему UDP так капризен в прокси-инфраструктуре, нужно вернуться к базовым понятиям транспортного уровня. Не пугайтесь: мы объясним всё простыми аналогиями.

Два транспортных протокола, две философии

В интернете данные передаются поверх двух основных транспортны]]>Fri, 24 Jul 2026 13:07:00 +0300