iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A 429 “Too Many Requests” response on a site behind Hostinger CDN almost always comes from the hosting server or a plugin, not from the CDN itself. Hostinger says the CDN returns a 429 of its own only as a last-resort defence during a DDoS attack, at request volumes far beyond normal traffic. The practical task is to identify which layer issued the response, then change only that layer.
Which layer issues the 429
Hostinger’s topic-specific support article states: “A 429 Too Many Requests response on a website behind Hostinger CDN almost always comes from the hosting server or a plugin, not from the Content Delivery Network (CDN).” (Hostinger CDN: 429 Too Many Requests errors)
That sentence sets the starting assumption. Three points follow from it:
Recommended Free Tools
- A response passing through the CDN is not proof the CDN generated it. Hostinger says the CDN passes through 429 responses produced by the hosting server and by plugins.
- The
x-hcdn-request-idheader only shows the response travelled through Hostinger CDN. Its presence does not tell you which component created the 429. - The CDN’s own 429 is a rare, attack-level response. It is covered in the section on attack traffic below.
Common origin-side sources
When the hosting server or a plugin is the source, Hostinger’s guidance points to two main groups:
- LiteSpeed per-visitor limits. The LiteSpeed web server on the hosting side can cap how many requests a single visitor address makes in a period.
- Application and plugin limiters. WordPress or other application plugins that throttle logins, contact or comment forms, or API requests. Security plugins, login limiters, form-spam protection, and API rate limiters all belong to this group.
The double-proxy problem
If another proxy such as Cloudflare sits in front of Hostinger CDN, the hosting server may see many different visitors as a handful of proxy addresses. A per-visitor limit then trips for traffic that is legitimate. Hostinger’s instruction is to keep only one CDN or proxy active. (Hostinger CDN vs Cloudflare)
In practice there are two configurations to choose between:
- Hostinger CDN only. Confirm this is the only active proxy for the domain, and use Hostinger’s dashboard and support path for it.
- Cloudflare only. Remove Hostinger CDN from the proxy chain, and manage the site through Cloudflare’s own settings and support.
The sources do not establish a universal winner. Choose the option that matches the features the site needs and the account you can manage.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →How to isolate the cause
Work through these steps in order. Changing settings before you have the request details makes the problem harder to reproduce.
- Reproduce the failure and record the details. Open the page in a browser, then open developer tools and select the Network tab. Load the page again, select the request that returns 429, and open Response Headers. Note the exact URL, the time, and the value of
x-hcdn-request-id. - Check for a second proxy. Confirm whether Cloudflare or another proxy is active for the same domain. If it is, resolve that first using the double-proxy section above.
- Review request-limiting plugin logs. Check security, login-limiter, form-spam, and API-limiter logs. Compare the visitor address and timestamp in the logs with the failed request. A matching entry points to the plugin.
- Temporarily disable Hostinger CDN. Turn it off from the hosting dashboard, wait a few minutes, and repeat the same request. Re-enable the CDN once the check is complete. (How to troubleshoot HTTP Error 429 at Hostinger)
- Check resource usage if limits are suspected. Review CPU and RAM usage in the dashboard. Only consider optimisation or a plan change if that data shows the site consistently reaching its plan limits.
Reading the result of the CDN-disabled test
| Observation | What it indicates | Next action |
|---|---|---|
| 429 continues with Hostinger CDN disabled | The hosting server or a plugin is the source | Work through plugin logs and LiteSpeed-side limits |
| 429 appears only while Hostinger CDN is enabled | The problem is on the CDN path | Contact Hostinger support with the request details listed below |
| 429 appears only for crawlers after a burst of requests to uncached pages | Crawler rate, as described in the crawler section | Verify the response layer first; do not change crawler settings from the request ID alone |
Settings that do not change the limit
- IP or country blocking rules do not raise or lower request limits. Hostinger’s guide says traffic-blocking rules are separate from rate limits, so adding one will not fix a 429.
- A plan upgrade is not a general fix. It only makes sense when resource data shows repeated plan-limit pressure, as described in step five above.
Crawlers and sequential requests
Hostinger states that ordinary crawler rates are not limited by the CDN’s DDoS protection. A fast burst of requests to uncached pages, such as a very large XML sitemap, can occasionally reach a rate limit. Crawlers retry occasional 429 responses automatically, so an isolated 429 in crawl logs is usually not a reason to change anything. (Hostinger CDN: Search engine crawlers and SEO)
Attack traffic
If Hostinger CDN itself returns a 429, Hostinger characterises it as a last-resort response to attack-level traffic. Hostinger’s guidance is to keep the CDN enabled and switch on Under Attack mode if the website is being targeted. Disabling the CDN during an attack removes the protection the CDN provides, so it is not a diagnostic step in that situation. (Hostinger CDN: Troubleshooting website errors)
Rank #4
When to contact Hostinger support
Contact support if ordinary visitors receive a 429 only while the CDN is enabled, or if an attack affects legitimate visitors. Include the following:
- The domain name
- The failing URL
- The time of the failure, including time zone
- The
x-hcdn-request-idvalue - The published IP addresses of any external service the site depends on, when that service is involved
Keep the results of the CDN-disabled test with the report. They show support which layer you have already ruled out.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
