What "bypass CAPTCHA" actually means (and doesn't)
Read any download manager's feature list and you'll find the same phrase: skips CAPTCHAs and countdown timers. It's a comfortable lie. reCAPTCHA, hCaptcha image challenges and Cloudflare Turnstile are built and updated by companies with every commercial reason to stay ahead of automated solvers. A desktop app written by one or two people is not quietly defeating Google's bot infrastructure in the background, and I'd be suspicious of anyone who claims otherwise.
Countdown timers are the same story. When a file host says wait 45 seconds, that number lives on their server. A client can lie to its own UI about how long it waited, but the download link on the other end does not unlock until the server says so. Anything that looks like a bypass is either counting down locally while the server counts down at the same time, or hiding the wait behind a paid API account you paid for separately.
Veloxar does neither. It treats the gatekeeping layer (Cloudflare pages, rate limits, wait screens, challenges) as a first-class part of the download pipeline. We cache what can be cached, solve what can be solved deterministically, honor the waits that have to be honored, and surface everything else with enough detail for you to actually do something about it.
Cookies have memory, so we do too
The most common thing a Cloudflare-protected host does is serve you a JavaScript challenge page once, wait for you to pass it, and then hand you a clearance cookie. That cookie is good for a while. Every subsequent request that carries it skates through the gate without touching the challenge at all.
This is the part most clients get wrong. They treat every request as independent, so each download hits the front door, each one gets challenged, and a host that would have happily served ten files in a row instead sees ten fresh challenge failures and starts turning up its defenses. Which is exactly when your IP stops being welcome.
Veloxar's AntiDDoSMiddleware wraps every plugin
request. Before firing the request, it asks the shared cookie
cache whether this host has given us a clearance cookie recently,
and if so, injects it. When a response comes back with new
Cloudflare cookies, they get stored against the host so the next
request on that host starts from cleared state. The code is tiny
-- a filter over HTTPCookie.cookies(withResponseHeaderFields:)
keyed against a known set of Cloudflare cookie names -- but it
is the difference between one challenge per session and one
challenge per file.
The six CAPTCHA types, and what we solve
Veloxar detects six distinct CAPTCHA families: reCAPTCHA, hCaptcha, Cloudflare Turnstile, FunCaptcha, arithmetic, and custom text prompts. It auto-solves exactly two of them -- arithmetic and simple text -- because those are the ones a solver has any honest chance against.
Arithmetic challenges are what they sound like: the page says "what is 7 + 4" and wants "11" in a form field. These are parseable. Custom text challenges, where a site says "type the word red to continue," are parseable too. Both are solvable deterministically without pretending to be a computer vision breakthrough.
For the other four (reCAPTCHA, hCaptcha, Turnstile, FunCaptcha)
the honest answer is that you need a human, a paid solving
service, or a headless browser instance you supply your own
credentials to. Veloxar detects them, extracts the site key
where it can (Turnstile extraction is a small regex on
sitekey), and surfaces a captchaRequired
error with the challenge type and URL attached. You see what's
blocking the download and you decide. No spinner pretending to
work.
Rate limits are a conversation, not a wall
The other half of the gatekeeping layer is the rate limit. A
host returns 429, sometimes with a Retry-After
header, sometimes without. A lot of clients respond by retrying
harder, which is how you escalate a slap on the wrist into a
real block. The better move is to retry less often, on fewer
connections, and remember what happened so you don't walk into
the same wall tomorrow.
Veloxar's HostRateLimitTracker keeps a per-host
concurrency budget. It starts at 8 parallel connections. Every
429 halves it. 8 becomes 4 becomes 2 becomes 1. Each hit also
stamps a 60-second cooldown on that host, and cooldowns stack
up to roughly 300 seconds when a host gets particularly hostile.
If a host is in cooldown, new downloads to that host wait their
turn instead of piling onto the refused queue.
The step-down is multiplicative because additive doesn't work. Dropping from 8 to 7 to 6 to 5 still hammers a host that wanted you at 1. Halving gets you to the conservative number in three strikes, not seven, and that difference is the difference between a host that forgives you and a host that starts blocking your IP.
The observations persist across runs. If a host rate-limited you yesterday, today's first download to that host starts at a lower concurrency ceiling, not the default 8. Same reason you lower your voice the second time you walk into a library: you already know the room.
The countdown is real, but you don't have to watch it
When a host says wait 45 seconds, Veloxar waits 45
seconds. There is no trick. What Veloxar does do is turn that
wait from dead time into visible time. Before the middleware
sleeps, it computes the waitUntil timestamp and
broadcasts a HostWaitEvent tagged with the host.
The queue manager picks it up, matches it to any active download
on that host, and the UI shows a live countdown: 44, 43, 42.
The cap is 120 seconds. If a host demands more than two minutes between attempts, Veloxar treats that as a refusal and fails the download cleanly. You can requeue it if you want. What you don't get is a spinner running for five minutes on a download that was never going to succeed in this window.
Tiny feature to describe, big one to live with. The worst thing a download manager can do is look frozen. A client that is visibly waiting out a rate limit feels like progress; a client that's invisibly doing the same thing feels like a bug you want to report.
On your screen
You drop in a batch of links from a file host that uses Cloudflare. The first download hits the challenge page, passes it, and banks the cookie. The next 49 downloads skip the challenge entirely because the cookie is on every request.
One of them gets a 429 anyway. Veloxar halves the concurrency ceiling for that host, waits out the cooldown you can see ticking down in the UI, and resumes at the lower ceiling. Two downloads later it gets another 429, halves again, and now that host is serving you one file at a time politely instead of eight files at a time angrily.
One URL lands on a Turnstile challenge. Veloxar does not pretend. It fails that specific download with a clear message saying what kind of challenge it is, and the other 49 continue. You deal with the one that needs you, and the rest of the queue finishes without you.
That's the whole pitch. Veloxar isn't magic at the gate. It's careful about which gates it can walk through and which ones it has to wait at, and it tells you about the ones you actually have to handle yourself. The marketing copy is less exciting than the competition's. The downloads are more likely to finish.