Migrating production infrastructure? Get up to ₹10,000 in migration credits. Apply now
voroaDocs
Platform Protections

DDoS protection for a service's Voroa address

What a denial of service attack does, how DDoS protection absorbs floods before they reach a service, what changes for uploads, slow requests and visitor IPs.

Availability

DDoS protection is available for every service’s Voroa address, and it is on by default. You can turn it off for any service in its settings.

Two layers of defence

A denial of service attack tries to make your service unavailable by sending far more traffic than it can answer. There are two very different layers of defence. Network-level protection sits in front of everything and drops obviously malicious floods before they reach any application, which is the only place a large volumetric attack can be handled at all. Application-level defence is your own code refusing to do expensive work for a client that is asking too often, which is what handles the much more common case of one badly behaved script. Rate limiting inside your own application is worth adding regardless of the platform.

What DDoS protection covers

Visitors and attack traffic reach the edge network first, which absorbs the flood and passes only real requests on to your service at its Voroa address

DDoS protection serves your service’s own Voroa address (<name>.onvoroa.com) through an edge network. That network absorbs floods of unwanted traffic - including large distributed attacks - before they reach your service, and per-visitor rate limiting keeps working as before.

It applies to your service’s Voroa address. A custom domain can go through the edge network too, on a paid plan - see Custom domains through the edge below.

What changes when it is on

Read these before you turn it on. Each one changes what your visitors or your code experience.

  • Uploads larger than 100 MB are refused. If your service accepts bigger files, send them to a storage service directly, or use a custom domain for that service.
  • A request that takes longer than 100 seconds to start answering times out. The visitor gets a timeout error (524). Long-running work should answer first - with a job id, for example - and carry on in the background.
  • WebSockets work, but an idle connection can be closed. Clients should reconnect, which most WebSocket libraries already do.
  • Find the visitor’s address by reading X-Forwarded-For from the right. First skip any private address at the end (10.x.x.x); Voroa adds one when your service runs on a separate server inside Voroa’s network. The next entry is the edge network server that connected to your service, and the entry just before it is the visitor. So on some services the visitor is the second-to-last entry, and on others the third-to-last. Anything further to the left was sent by the visitor and can be forged. Do not use X-Real-Ip: it holds Voroa’s internal address, not the visitor’s. Do not trust any other client-address header a request carries (for example CF-Connecting-IP or True-Client-IP): a visitor who reaches your service’s address directly can set them to anything.

When it does not apply

DDoS protection stays inactive for a service that has:

  • A custom domain, including a wildcard one. Your domain points at your service’s Voroa address, and it would stop working through the edge. The service’s settings say this in plain words.
  • Inbound IP rules. An address list needs each visitor’s own address, which cannot be passed on safely through the edge. See Inbound IP rules.

Your choice is kept in both cases. Remove the custom domains or the IP rules and it applies again.

Custom domains through the edge

Where it is offered, a custom domain on a paid plan can be served through the edge network as well. It does not apply to a wildcard domain, to a preview, or to a service with inbound IP rules.

  1. Voroa prepares the domain first. Nothing changes for your visitors while it does.
  2. When it is ready, the domain’s row says so and View DNS shows the new record: a CNAME to the edge address. Change that one record at your DNS provider. Your site keeps loading over HTTP during the change, but HTTPS can fail for up to about an hour after it, while the new certificate is issued. The domain’s row warns you about this before you change anything. To avoid it, see Switch with no downtime below.
  3. Once the new record is visible, the domain is switching on. This finishes within 48 hours, the time older DNS answers can still be cached.

Switch with no downtime

You can have the certificate issued before you change the record, so HTTPS keeps working through the change.

  1. On the domain’s row, press Switch with no downtime. It is shown only while the domain is ready and its record has not been changed yet.
  2. Open View DNS and add the TXT records listed under “Certificate” at your DNS provider. There are usually two with the same name - add both. Do not change the CNAME yet.
  3. Wait until the row says The certificate is ready. This normally takes a few minutes after the TXT records are visible.
  4. Now change the record shown in View DNS. Your site switches with no downtime. You can delete the TXT records afterwards.

If you change the record before the certificate is ready, the domain falls back to the standard method and HTTPS can fail for up to about an hour, as above. Use the standard method on the row turns this off at any time. After the certificate is issued, switching back keeps your current certificate. It also lets you add a wildcard for this domain. It is not available for a root domain, or for a domain that is the base of a wildcard domain (for shop.example.com while you also have *.shop.example.com), because both need the same DNS name.

A root domain (for example example.com) can only use this if your DNS provider supports ALIAS, ANAME or CNAME flattening at the root - an A record cannot point at the edge network. The domain’s row asks you to confirm that before anything is prepared.

A domain whose record is an address on your own proxy or CDN does not reach the edge network, so DDoS protection is not active for it. Its row says so, and the domain and its HTTPS keep working exactly as they are.

Turning it off, or removing the domain. Change the record back first: View DNS shows the direct record again. Your site keeps working until you do. If you remove a domain whose record still points at the edge, that domain stops working.

Turning it off or on

  1. Open the service and go to Settings, then DDoS Protection.
  2. Read the list of what changes, then use the DDoS protection switch.

The change is applied within a few minutes. Nothing is redeployed and your service is not restarted. While a change is being applied the switch cannot be changed again.

Last updated November 3, 2026