Imagine this: you wrote a client that makes requests to a website, and everything works. Then suddenly errors start piling up, workers hang, and the server replies with the mysterious code 429. Sound familiar? Then this guide is for you. We'll break down how to build an HTTP client that doesn't panic at the first problem, but behaves politely and resiliently.

Introduction: why 429 is not an error, but a signal

Many developers see code 429 and think: something broke. In reality, the server is telling you something very specific: you're sending too many requests, slow down. It's not a permanent refusal or a block. It's a request to ease up. And if you listen correctly, your client will become reliable.

What the reader will get in the end

By the end of this tutorial, you'll have a working HTTP client that can do several important things. It correctly handles code 429 and respects the Retry-After header. It uses exponential backoff with jitter so it doesn't create a storm of retries. It limits concurrency so it doesn't overwhelm the target server. And it never hangs thanks to proper timeouts.

You'll get ready-to-use code snippets in three languages: Python (using the httpx library and urllib3 Retry), Node.js, and Go. Each snippet you can plug into your own project and adapt to your needs.

Who this guide is for

This guide is aimed at beginner developers who already know how to make simple HTTP requests but haven't yet dealt with production load. However, it also includes advanced blocks: circuit br]]>Wed, 29 Jul 2026 15:29:00 +0300https://www.proxeon.net/en/pages/dns-through-proxy-socks5-vs-socks5h-remote-resolution-and-leaks.htmlDNS Through Proxy: socks5 vs socks5h, Remote Resolution, and Leaks

Picture this. You've connected a proxy from the right region, checked your IP address — everything is correct, the city and country match. But the target website stubbornly shows you the wrong content, and the anti-fraud system flags your session as suspicious. Sound familiar? Chances are you've encountered one of the most insidious issues when working with proxies — a DNS leak or the wrong path for domain name resolution.

This article is a comprehensive guide to exactly how domain names are resolved into IP addresses when traffic goes through a proxy. We'll break down the fundamental differences between socks5 and socks5h schemes, who sends the DNS query and at what stage, why a website sometimes sees a completely different region than you expected, and how to set up remote resolution in popular clients and libraries. The topic is narrow but incredibly important. It's at the name resolution stage that thousands of seemingly well-configured setups fall apart.

Introduction: why the proxy is connected but the site sees a different region

Let's start with the symptom that brings most readers to this topic. You've configured a proxy. Your IP address is correctly masked — you can easily verify that on any IP detection service. Yet something is off: the site serves localization from another country, the CDN directs you to an unexpected node, and sometimes the target resource's security system blocks your request for no apparent reason.

The reason is almost always the same. Your HTTP or application traffic does go through the proxy, but the DNS query — the very request that turns a name l]]>Mon, 27 Jul 2026 13:40:00 +0300https://www.proxeon.net/en/pages/udp-over-socks5-the-udp-associate-command-why-http-proxies-dont-support-udp-and-how-to-test-it.htmlUDP over SOCKS5: The UDP ASSOCIATE Command, Why HTTP Proxies Don't Support UDP, and How to Test It

Familiar situation: you set up a proxy, your browser opens websites, your scraper collects data, everything looks perfect. Then you start a video call, and the other person can't hear you. Or you join an online game, and the match won't connect. Or you launch a voice chat, and it's silent. The proxy works, right? It does. But something is broken at a deep level, and understanding it without knowledge of transport is nearly impossible.

The reason is almost always the same: your proxy does not allow UDP traffic. And this isn't a malfunction, it's a fundamental property. Some types of proxies can handle UDP by standard, others cannot at all. The difference between these two worlds determines whether you'll have real-time communication on the internet or just webpage loading.

In this guide, we'll break down the topic from the very fundamentals to practical testing tools. You'll learn how the UDP ASSOCIATE command works in the SOCKS5 protocol, why HTTP proxies using the CONNECT method physically cannot transfer datagrams, what exactly breaks for a user without UDP, and how to independently, in just a few minutes, test any proxy for real UDP support. We'll talk only about transport: no analysis of choosing between proxy types, no instructions for configuring specific applications.

Basics: TCP vs. UDP, Datagrams, and Where Proxies Operate

To understand why UDP is so temperamental in proxy infrastructure, we need to go back to the basic concepts of the transport layer. Don't worry: we'll explain everything with simple analogies.

Two Transport Protocols,]]>Fri, 24 Jul 2026 13:07:00 +0300