{"id":18714,"date":"2026-09-23T04:06:42","date_gmt":"2026-09-23T04:06:42","guid":{"rendered":"https:\/\/www.hostinger.com\/support\/?p=18714"},"modified":"2026-09-23T04:06:42","modified_gmt":"2026-09-23T04:06:42","slug":"hostinger-cdn-429-too-many-requests-errors","status":"publish","type":"post","link":"https:\/\/www.hostinger.com\/support\/hostinger-cdn-429-too-many-requests-errors\/","title":{"rendered":"Hostinger CDN: 429 Too Many Requests errors"},"content":{"rendered":"

A 429 Too Many Requests response on a website behind Hostinger CDN<\/a> almost always comes from the hosting server or a plugin, not from the Content Delivery Network (CDN). Hostinger CDN itself returns 429<\/a> only as a last-resort protection during a DDoS<\/a> (Distributed Denial of Service) attack, when a website or a single address receives request volumes far above anything regular traffic produces. Finding where the response comes from resolves most cases.<\/p>

When Hostinger CDN returns a 429 error<\/h2>

Hostinger CDN limits request rates per website and per visitor IP address as one of its DDoS protections<\/a>, and it applies the limits only at attack-level volumes. Regular traffic does not reach them: visitors sharing one address through an office network, a mobile carrier, or a VPN (Virtual Private Network), busy administrators working in wp-admin, page builders, uptime monitors, and normal crawling all stay far below the thresholds.<\/p>

The website is receiving attack-level traffic if Hostinger CDN does return 429, and the CDN is keeping it away from your hosting server. Visitors who share an address range with the attack source can be affected as well during an attack. The browser verification page usually appears before rate limiting does, because automatic attack protection challenges suspicious traffic first (see Hostinger CDN: The browser verification page<\/a>). Keep the CDN enabled during an attack, and enable Under Attack mode if the website is the target (see Hostinger CDN: The Under Attack mode<\/a>).<\/p>

Other sources of 429 responses on your website<\/h2>

Most 429 responses that visitors report come from one of three places behind the CDN.<\/p>

The hosting server applies its own per-visitor limits through LiteSpeed Web Server, answering with 429<\/a> or 503<\/a> when a single address sends too many requests. Hostinger CDN passes these responses through unchanged, so they also carry the x-hcdn-request-id header<\/code> — the header shows that the response travelled through the CDN, not that the CDN generated it.<\/p>

WordPress and application plugins return 429 by design when they detect repeated requests from one address, including security plugins, login limiters, form spam protection, and API (Application Programming Interface) rate limiters.<\/p>

Another proxy in front of Hostinger CDN causes per-visitor limits on the hosting side to trigger for everyone at once. When Cloudflare or a similar service proxies the website before Hostinger CDN, your hosting server sees the whole audience arriving from a handful of proxy addresses. Keep only one service active, as described in Hostinger CDN vs Cloudflare<\/a>.<\/p>

How to find the source of a 429 error<\/h2>
    \n
  1. Note the exact URL, the time, and the x-hcdn-request-id<\/code> header of a failing response: open the browser developer tools (F12), select the Network<\/strong> tab, click the request marked 429, and check Response Headers<\/strong>.<\/li>\n
  2. Check whether another proxy is active for the domain. Disable the Cloudflare proxy or switch to a single CDN if the domain uses Cloudflare nameservers with proxying enabled.<\/li>\n
  3. Review plugins<\/a> that limit requests — security plugins, login limiters, and API rate limiters — and their logs for the failing address and time.<\/li>\n
  4. Confirm where the response comes from. Go to Hostinger dashboard → Websites → Dashboard → Performance → CDN<\/strong>, click Disable<\/strong>, wait a few minutes, and repeat the failing request. A 429 response that persists with the CDN disabled comes from your hosting server or a plugin. Re-enable Hostinger CDN after the test.<\/li>\n<\/ol>

    NOTES<\/strong><\/p>