HTTP 403 and 429 responses come from the source site, not from Dingdok. They mean the server is refusing or throttling requests. The fix is almost always to slow down and retry, not to find a workaround.
What the codes mean
- 403 Forbidden — the server rejects the request. Often triggered by a missing or expired token, unusual traffic, or a region block.
- 429 Too Many Requests — you are sending requests faster than the site allows.
Both are protective responses. Dingdok reports them honestly instead of retrying silently forever.
Immediate steps
- Wait. Give the site a few minutes to reset its counters.
- Pause the queue, then retry the failed items.
- Lower concurrency under Settings → Network. Two parallel downloads is gentler than eight.
- Add a delay between items using the same setting panel.
Reducing repeat failures
- Download large batches at a lower concurrency, and schedule them off-peak.
- Avoid re-adding the same links repeatedly; each attempt counts against the limit.
- Keep Dingdok updated so request patterns match what the site expects.
What does not help
- Retrying immediately in a tight loop — this makes a 429 worse.
- Raising concurrency — it will trip the limit sooner.
- Trying to defeat the block — Dingdok does not bypass access controls, and doing so would violate site terms.
When it is really a 403
If a single item returns 403 while others from the same site work, the link may be private or expired. Reopen it in a browser and grab a fresh URL.
Reporting a persistent error
If a site returns 403/429 consistently at low concurrency for public links, send us:
- The platform name.
- A sample link.
- The exact status text and your Dingdok version.
Related reading
See “Fix ‘Parse failed’ errors” if the item never gets far enough to return an HTTP status.