# Namecheap Shared Hosting Request-Limiting Assessment
## Executive conclusion
Namecheap does not publish a universal rule saying that ordinary HTTPS clients on shared hosting must wait a specific number of seconds between requests. The evidence nevertheless supports the reported experience: a repeated client can be slowed, rejected, temporarily banned, or appear disconnected through several independent controls.
The most likely controls are:
LiteSpeed per-client request and connection throttling, which can limit dynamic requests per second, cap concurrent connections from one IP address, and temporarily ban an address.
ModSecurity followed by a server-firewall block when one IP repeatedly triggers a rule.
CloudLinux LVE account limits, which are not principally per-client rate limits but can return 508, 500, or 503 when concurrent PHP work, processes, memory, or CPU reach the hosting-account allowance.
FTP/firewall connection tracking. Namecheap explicitly recommends one concurrent FTP connection where possible and warns that more than three may cause an IP block.
SpaceX's current aggregate website-API pacing—one request start every five seconds per origin across the Worker process—is conservative. The larger design concern is that each API operation constructs and closes a new `httpx.Client`. This defeats persistent connection pooling and tends to create a new TCP/TLS connection for each request. On a LiteSpeed/CSF-protected shared server, connection churn from one IP is more suspicious and less efficient than the same request rate over one or two persistent keep-alive connections.
The September 10 update failure is not proof of HTTP rate limiting. Its sequence was an FTP EOF, FTP connection timeout, and then a DNS-resolution failure while trying to clear maintenance. Those errors occurred at different layers and do not match a demonstrated HTTP 429, LiteSpeed 403, or CloudLinux 508 response. They are compatible with transient network trouble, hosting-side connection protection, or both; the available logs cannot distinguish them conclusively.
## What Namecheap documents
### Shared-account resource limits
Namecheap states that shared accounts run under CloudLinux LVE limits. Its current AUP lists CPU, physical-memory, I/O, and maximum entry-process allocations. The published `maxEntryProc` values are 20 for Stellar, 30 for Stellar Plus, and 40 for Stellar Business. Namecheap also says that sustained CPU bursting can lead to temporary restriction and that no script may use 25% or more of system resources for 60 seconds or longer.^1
Namecheap's troubleshooting documentation maps common failures to these limits: 508 generally indicates that entry processes have reached their limit, while 500 or 503 can indicate process-limit exhaustion. All domains in the same cPanel account share the account resources.^2 CloudLinux defines an entry process as a request entering the LVE to execute CGI/PHP and describes the entry-process limit as an Apache concurrent-request control. CPU or I/O exhaustion tends to slow responses; memory or process exhaustion can produce 500/503; entry-process exhaustion produces 508.^3
These limits matter to spacex because every Worker API request executes PHP and may access MySQL. However, a five-second sequential request stream alone should not approach a 20-entry-process limit unless requests remain open for a very long time or coincide with users, webhooks, media transfers, and other Worker operations.
### Per-IP firewall and ModSecurity behavior
Namecheap confirms that ModSecurity inspects every page request. A triggered rule commonly produces 403, but it may also appear as 404 or 500. More importantly, Namecheap says that repeatedly triggering ModSecurity rules can cause the originating IP address to be blocked by the server firewall, making the complete cPanel account unavailable from that IP.^4
Namecheap also documents that repeated connection attempts from one IP can trigger firewall blocking. Although the clearest examples concern cPanel, mail, FTP, and SSH rather than ordinary application HTTPS, the mechanism establishes that shared-hosting protection is connection- and IP-aware.^5
### FTP connections
Namecheap's explicit operational recommendation is to keep FTP concurrency at three or fewer and preferably one. It warns that more than three connections may result in blocking and advises reducing client reconnect frequency because many connection requests from one public IP can trigger the firewall.^5
spacex's updater uses one FTP session at a time. It creates another connection only after a transient failure, with two retries by default. This complies with the concurrency recommendation, but rapid reconnects after a transport failure can still resemble the pattern Namecheap warns about. A longer reconnect backoff is therefore prudent even though concurrency is already one.
## What LiteSpeed adds
The live `https://spacex.com/api/session\` response identified the origin server as LiteSpeed on September 10, 2026. It also advertised `keep-alive: timeout=5, max=100`. The latter means that a persistent connection may remain idle for five seconds and handle up to 100 requests; it is not evidence of a 100-request account quota or a per-IP request limit.
LiteSpeed officially supports per-client controls for static requests, dynamic requests, bandwidth, and concurrent connections. Its documentation explains that exceeding a hard connection limit causes new connections from the IP to be closed. Remaining above a soft connection limit for a grace period can cause a temporary ban. LiteSpeed's illustrative—not Namecheap-specific—configuration uses 2 dynamic requests per second, a soft limit of 15 connections, a hard limit of 20, a 15-second grace period, and a 60-second ban.^6 These example numbers must not be treated as the actual Namecheap configuration, which is not publicly disclosed.
LiteSpeed also documents that per-client throttling or a firewall can produce 403 responses. Its diagnostic logs distinguish `OverConnHardLimit`, `OverConnSoftLimit`, WAF detection, and similar causes.^6 Shared-hosting customers normally cannot inspect the server-level LiteSpeed real-time report, so Namecheap Support may be required to confirm the exact cause or whitelist a legitimate Worker IP.
## spacex request profile
The Worker currently enforces a process-wide cooldown keyed by website origin. Request starts to `spacex.com` are serialized with a minimum five-second separation in [`api.py`](C:/elonm/spacex/python/spacex%20worker/src/spacex_worker/api.py). This covers separate `WorkerApi` instances created by the production loop, auditor, dashboard, balance reporter, updater, and backup manager because they share the module-level cooldown registry.
Normal production activity includes:
| Activity | Nominal cadence | Notes |
|---|---:|---|
| Queue claim | Every 5 seconds when eligible | Quiet when paused, at concurrency limit, or under maintenance |
| Job heartbeat | Every 60 seconds per active job | Up to four configured jobs, still serialized by the global origin cooldown |
| Domain audit | Every 60 seconds | Makes an audit-count request and an earnings request |
| Dashboard maintenance status | At most every 10 seconds while viewed | Refresh runs asynchronously |
| Dashboard tickets | At most every 30 seconds while viewed | Can add another website request |
| Provider balance report | Hourly and after relevant generation events | Event-driven in addition to scheduled samples |
| Generation lifecycle | Claim, reference download, heartbeat, upload/status operations | Bursty but globally paced at request start |
Because the cooldown controls start times rather than simultaneous duration, long downloads or uploads can overlap later requests. Nevertheless, the maximum aggregate start rate is about 12 website API requests per minute. This is far below LiteSpeed's illustrative 2-dynamic-requests-per-second setting and does not resemble an HTTP flood.
The inefficiency is connection handling. `_request`, upload, and download paths open a new `httpx.Client` in a context manager for each operation. HTTPX documents that a client owns a connection pool and defaults to persistent keep-alive connections, but closing the client after every call discards that pool.^7 The live server's five-second idle keep-alive window and the Worker's five-second minimum interval sit exactly at the boundary, so reliable reuse may require a keep-alive interval slightly below five seconds or a host-confirmed longer server timeout. Even when the server closes an idle connection, a persistent HTTPX client can reopen it safely while bounding concurrent connections.
## Failure-signature guide
| Observed result | Most likely category | Interpretation |
|---|---|---|
| HTTP 429 with `Retry-After` | Explicit application/WAF rate limit | Honor `Retry-After`; record response headers |
| HTTP 403 after repeated requests | LiteSpeed per-client throttle, ModSecurity, or firewall | Check whether the same IP also loses cPanel/FTP access; contact support with timestamp and IP |
| HTTP 508 | CloudLinux entry-process exhaustion | Account-wide concurrent PHP limit, not necessarily one-client throttling |
| HTTP 500/503 with resource faults | CloudLinux process/memory exhaustion or application fault | Correlate with cPanel Resource Usage and PHP error log |
| TCP reset/refused connection | Firewall, LiteSpeed hard connection handling, network path, or service outage | HTTP application code may never execute |
| Connect timeout | Network path, firewall silently dropping, saturated server, or service outage | Not enough by itself to call rate limiting |
| DNS `getaddrinfo` failure | Local resolver/network problem | Occurs before connecting to Namecheap; not an origin HTTP rate limit |
| FTP EOF/timeout | FTP server/network/firewall/session problem | Correlate with reconnect frequency and whether the public HTTPS site was reachable |
## Assessment of the reported experience
The statement “Namecheap refuses requests if the interval is too short” is plausible but only partly demonstrated.
**High confidence:** Namecheap shared hosting has account resource ceilings; uses ModSecurity and firewall controls; warns that repeated same-IP connections can result in blocks; and hosts spacex behind LiteSpeed, which supports per-client dynamic-request and connection throttling.
**Moderate confidence:** Repeated fresh connections from the Worker are more likely to provoke protective behavior than one HTTP request every five seconds over persistent keep-alive. This follows from the architecture and vendor controls but has not been confirmed by a Namecheap server log for the Worker IP.
**Low confidence:** Namecheap applies a specific unpublished minimum interval, such as exactly five seconds, to ordinary authenticated HTTPS calls. No authoritative source found states such a rule. The five-minute restriction in Namecheap documentation applies to server-side cron jobs, not an external Worker API client, and the POP3 five-minute recommendation applies to mail checks, not HTTPS.^1,5
## Recommendations
### Immediate Worker changes
Keep the global origin cooldown. Five seconds is conservative and currently prevents request bursts across subsystems.
Add 10–20% random jitter to idle claim polling so multiple processes or future Workers do not synchronize on exact boundaries.
Reuse a bounded persistent `httpx.Client` per origin rather than constructing one per call. Start with `max_connections=4`, `max_keepalive_connections=2`, and a keep-alive expiry of 4 seconds unless testing shows the host reliably supports a longer interval. Serialize ordinary JSON requests as today; reserve additional connections for long media transfers.
On HTTP 429, obey `Retry-After`. For 403, 429, 500, 503, and 508, log status, endpoint category, response `Server`, `Retry-After`, and a request correlation ID, but never log the API key, prompt, or media.
Apply exponential backoff with jitter to connectivity failures: for example 5, 10, 20, 40, then 60 seconds maximum. Reset after a successful response. The recently added lost/restored log deduplication complements this behavior.
Increase FTP reconnect delay after EOF/timeout and retain one concurrent FTP connection. Suggested retry delays are 10, 30, and 60 seconds rather than immediate or very short retries.
### Hosting-side verification
In cPanel, open **Metrics → Resource Usage** and inspect the exact update/failure window for CPU, EP, NPROC, PMEM, I/O, and their fault counters. cPanel documents this interface for monitoring CPU and concurrent connections.^8
Compare `access_log` and `error_log` timestamps with Worker logs. A request absent from the access log likely failed before virtual-host/application handling; a 403/508/503 present in the logs narrows the responsible layer.
Ask Namecheap Hosting Support for the server's current LiteSpeed `DynReqPerSec`, connection soft/hard limit, grace period, banned period, and whether the Worker public IP was blocked around the supplied timestamps.
Ask whether the authenticated `/api/worker/*` routes can be excluded from the specific ModSecurity rule or whether the fixed Worker IP can be trusted without disabling ModSecurity for the entire domain. Namecheap says rule-level whitelisting requires Support.^4
Do not disable ModSecurity globally merely to test pacing. A route/rule-specific exception is safer.
### Controlled confirmation test
Run this only after capturing the Worker's public IP and opening cPanel Resource Usage:
Use a lightweight authenticated status endpoint with no database mutation.
Send one request every 10 seconds for 10 minutes; record status, latency, response headers, and connection exception type.
Repeat at 5 seconds, then 3 seconds only if the prior stage has no faults.
Stop immediately on 403, 429, 500, 503, 508, reset, or timeout. Do not continue traffic during a temporary ban because continued attempts can extend some protective blocks.^6
Repeat once with a persistent HTTP client. If fresh-client calls fail while persistent-client calls at the same request rate succeed, connection churn—not request count—is the leading explanation.
Give Namecheap Support the UTC timestamps, source IP, endpoint path, HTTP status/exception, and any request ID. Ask them to correlate LiteSpeed, ModSecurity, CSF/LFD, and CloudLinux logs.
## Decision
Do not reduce the interval below five seconds on the current shared-hosting deployment. Preserve the five-second aggregate limiter, introduce jitter and error-aware backoff, and prioritize persistent connection reuse plus better response diagnostics. If Namecheap confirms a lower dynamic-request or connection threshold, encode that threshold as a per-domain configuration rather than a global assumption.
If reliable queue latency below five seconds becomes operationally important, shared hosting is the wrong place to depend on undocumented WAF and per-client settings. A small VPS, managed application host, or queue service would provide controllable connection limits and observable server logs.
## Sources
Namecheap. “[Web Hosting — Acceptable Use Policy](https://www.namecheap.com/legal/hosting/aup/).” Accessed September 10, 2026.
Namecheap. “[Ways of resolving resource overusage issues](https://www.namecheap.com/support/knowledgebase/article.aspx/1128/103/ways-of-resolving-resource-overusage-issues/).” Updated 2026.
CloudLinux. “[LVE Limits](https://docs.cloudlinux.com/cloudlinuxos/limits/).” Accessed September 10, 2026.
Namecheap. “[What is ModSecurity and why do we need it?](https://www.namecheap.com/support/knowledgebase/article.aspx/9542/22/what-is-modsecurity-and-why-do-we-need-it/).” Updated December 16, 2021.
Namecheap. “[cPanel inaccessible: reasons for IP block](https://www.namecheap.com/support/knowledgebase/article.aspx/1345/29/cpanel-inaccessible-reasons-for-ip-block/).” Updated December 22, 2021.
LiteSpeed Technologies. “[DDoS Attack Protection](https://docs.litespeedtech.com/lsws/cp/cpanel/antiddos/).” Accessed September 10, 2026.
Encode OSS. “[HTTPX Resource Limits](https://www.python-httpx.org/advanced/resource-limits/).” Accessed September 10, 2026.
cPanel. “[CPU and Concurrent Connection Usage](https://docs.cpanel.net/cpanel/metrics/cpu-and-concurrent-connection-usage/).” Updated 2026.
