vDDoS-Protection: a script-installed DDoS reverse proxy that still calls itself beta

A reverse proxy that answers bots with a challenge instead of the origin

vDDoS-Protection describes itself as a HTTP(S) DDoS Protection Reverse Proxy, and the repository topic list spells out the mechanism behind that name. The topics include ddos-detection, ddos-mitigation, cookie-challenge-response, http-challenge-response, recaptcha-robot-challenge and robot-mitigator, which together point to a filter that keeps questionable clients busy with a challenge while letting genuine visitors reach the backend.

That is a different design from a rate limiter or a blocklist. A blocklist drops traffic it has decided is bad. A challenge-response filter asks the client to prove it can run JavaScript and hold a cookie, and lets the request through when the answer comes back correct. The repository listing backs that reading: there is an aes.min.js.txt file and three user-agent list files, user-agents1.txt through user-agents3.txt, which are the kind of assets a browser check needs.

For the target audience the distinction matters. A site owner who is being hammered by scrapers and credential-stuffing bots needs something that removes the cheap bot traffic without dropping the visitors, and a site owner facing a true volumetric flood needs a network-level answer instead. vDDoS-Protection sits in the first category, and the README does not claim otherwise.

The installer is a single wget line with an interactive menu

There is no package manager path here. The README gives one command that pulls a shell script from the master branch, makes it executable and runs it. The script then presents a menu.

wget https://raw.githubusercontent.com/duy13/vDDoS-Protection/master/latest.sh ; chmod 700 latest.sh ; bash latest.sh

After that the script prints a numbered menu and waits for a keystroke:

 1. MASTER
 2. SLAVE
 3. REMOVE ALL

 0. Exit

The MASTER and SLAVE entries are the interesting part. They suggest a deployment with more than one node, where one instance is the primary and another takes a supporting role, although the README does not explain how the two communicate, which port they use, or what happens if the master disappears. The REMOVE ALL entry is a clean uninstall path, which is more than many small shell installers offer.

You should read the script before running it. It is fetched over the network from a moving branch name, made executable and run with bash, and the menu only appears after the download completes. Anyone deploying this into production should download latest.sh first, inspect it, and then run it.

conf.d, GeoIP and the html directory are the whole configuration surface

Configuration lives in directories rather than a single documented file. The top-level entries include conf.d/, a GeoIP/ directory, an html/ directory, ab.zip, aes.min.js.txt, md5sum.txt and CHANGELOG.txt, plus a set of user-agent lists.

The conf.d/ name is the familiar convention for per-file configuration on Linux, and the GeoIP/ directory implies that source geography is used to decide how a request is treated. The html/ directory most likely holds the pages served to a client that has to pass a check. The README itself points elsewhere for the details: it says to check the homepage at vddos.voduy.com for installation and usage documentation. That means the configuration keys, the challenge parameters and the rules for what counts as malicious traffic are not documented in the repository text, and an evaluator has to read them off the running system or the linked documentation.

The CHANGELOG.txt entry is worth opening early too, because the repository has no GitHub releases. Version history lives in a text file inside a repository whose releases page is empty, so upgrade decisions depend on reading that file and inspecting the installer.

Legacy build artifacts for CentOS 5 and 6 sit next to the modern ones

The repository listing is dominated by archived binaries. There are vddos-1.10.1 through vddos-1.13.10 releases, and each version ships as a centos5, centos6, centos7 and cloudlinux5, cloudlinux6, cloudlinux7 package, plus a source tarball. CentOS 5 and 6 reached end of life years ago, and CloudLinux 5 and 6 are similarly dated. Those files are history, not supported targets.

What matters for a current deployment is the stated system requirement list:

* CentOS/AlmaLinux/RockyLinux 8/9 x86_64
* Ubuntu Server LTS 20/22/24 x86_64
* Debian Server 11/12 x86_64

That list covers the mainstream enterprise Linux distributions on x86_64 and says nothing about ARM, nothing about Alpine, and nothing about any other operating system. The primary language of the repository is Shell, which fits a distribution-specific installer well but also means the supported-platform list in the README is the only contract you get.

An operator on a non-x86_64 host or on a minimal container base has no documented path. There is no Dockerfile in the top-level entries, no container image reference and no package for Debian-style hosts either, so the supported platforms are exactly the ones named above.

The project states plainly that it is still in beta

The README includes a short notice under the configuration heading, and it is the most important line in the whole file:

Still in beta, use at your own risk! It is provided without any warranty!

Taken with the empty releases list, that is the honest summary of the project's maturity. There is no tagged version, no changelog entry describing stability guarantees, and no support commitment. The newest version directory visible in the listing is 1.13.10, which tells you the numeric version scheme exists without telling you what changed in it.

Licence is another open question. No licence file appears among the top-level entries, so there is nothing to read there and no stated grant of use, modification or redistribution in the README. That is not a legal opinion, and it is not a conclusion about whether anyone may run the software. It is simply a missing piece of documentation. For a proxy that sits in front of a live site, an operator should settle that question with the author before treating the deployment as settled, because the same uncertainty applies to whether forks and internal modifications are permitted.

For maintenance activity, the last push was on 2026-06-14. That is a recent commit by any reasonable measure, so the project does not read as abandoned, but recent commits and a stable release contract are different things.

Where a reverse proxy filter stops and the network provider starts

Compare this with the other approach to the same problem. A network edge service, whether a scrubbing provider or a hardware firewall, absorbs traffic before it reaches your host, filtering by source addresses, protocol fingerprints and volumetric thresholds at the point where the traffic enters your network. Nothing about your application, and nothing about JavaScript execution, is needed to make that decision. The cost is that traffic still crosses the public internet toward you and is billed by the byte or by the cleaning policy.

vDDoS-Protection makes its decision from inside the request. It can look at headers, user-agent strings, source geography and the outcome of a JavaScript challenge, and it can distinguish a real browser from a script by asking the client to prove it. That is why it can remove bot traffic that a volumetric filter would pass through untouched, and why it cannot stop a genuine flood that arrives from many distributed residential addresses, because each of those clients can complete a challenge.

The practical read: this tool complements edge scrubbing rather than replacing it. Deploy it to cut out the background bot traffic that inflates origin logs and wastes CPU, and keep a network-level answer for the events where the traffic volume itself is the weapon.

An upgrade path that depends on an unpinned script from a branch

Because the install command always fetches from master, two operators running it on different days can end up with different code, and neither can say from the command line alone which version they have. The md5sum.txt file in the top-level entries suggests that checksums are published for the downloadable artifacts, but the README does not explain how they are meant to be used, and the wget line contains no verification step.

Upgrading therefore means running the installer again and choosing the same role from the menu, with no documented flags for version pinning, no documented rollback, and no notes on what happens to the existing configuration under conf.d/. The REMOVE ALL menu entry suggests that reinstalling is the intended path, but the README does not say whether that wipes your conf.d/ files.

For a service that sits on the request path, that is the operational cost to price in. Test the install, the role selection and the removal path on a throwaway host of the same distribution first, and keep your own copy of whatever you put in conf.d/.

Editorial conclusion

Operators who run CentOS, AlmaLinux, RockyLinux, Ubuntu LTS or Debian servers on x86_64 and can tolerate an unauthenticated installer and a self-described beta can put vDDoS-Protection in front of an origin as a cheap first layer, but anyone who needs a stated support commitment, a documented upgrade path, or a licence with known terms should verify the installer script and the conf.d/ settings on a staging host first, and should not rely on it as the only mitigation for a serious attack.

Frequently asked questions

Official sources

1. duy13/vDDoS-Protection on GitHub
2. Issues
3. Project website
4. README