How to Protect Your Server from DDoS Attacks with Proxy: Setup in 15 Minutes

DDoS attacks can paralyze the operation of any web service in a matter of minutes. Attackers send thousands of requests from different IP addresses, overwhelming the server and making it inaccessible to real users. Proxy servers are one of the effective protection tools that allow filtering malicious traffic, distributing load, and hiding the real IP address of your server.

In this guide, we will discuss how to set up proxies for DDoS protection, which types of proxies to use, and how to build a multi-layered security system. The material is aimed at system administrators, web service owners, and DevOps specialists.

How DDoS Attacks Work and Why Proxies Help

DDoS (Distributed Denial of Service) is a distributed denial-of-service attack. An attacker uses a botnet of thousands of infected devices that simultaneously send requests to your server. The goal is to exhaust the server's resources (CPU, memory, bandwidth) and make it unavailable to legitimate users.

The main types of DDoS attacks are:

• Volumetric attacks — fill the bandwidth with a massive amount of traffic (DNS amplification, UDP flood)
• Protocol attacks — exploit vulnerabilities in network protocols (SYN flood, Ping of Death)
• Application layer attacks — mimic legitimate requests to a web application (HTTP flood, Slowloris)

Proxy servers help protect against DDoS in several ways:

• Hiding the real IP address of the server — attackers only see the proxy's IP, not your main server's
• Filtering malicious traffic — proxies analyze requests and block suspicious ones
• Load distribution — multiple proxy servers distribute traffic among backend servers
• Rate limiting — limiting the number of requests from a single IP address
• Caching static content — reduces the load on the main server

It is important to understand that proxies are not a panacea for all types of DDoS. Powerful volumetric attacks can saturate the bandwidth to the proxy server. Therefore, proxies are effective in combination with other protection methods: CDN, cloud anti-DDoS services (Cloudflare, AWS Shield), firewalls.

Types of Proxies for DDoS Protection: Reverse vs Forward

Two main types of proxy servers are used for DDoS protection:

Reverse Proxies

A reverse proxy sits in front of your web server and accepts all incoming requests from clients. Clients interact only with the proxy, unaware of the real IP address of your server. This is the primary tool for DDoS protection.

Popular solutions for reverse proxies include:

• Nginx — a fast and lightweight web server with reverse proxy capabilities
• HAProxy — a specialized load balancer with powerful filtering capabilities
• Apache mod_proxy — a module for Apache, less performant than Nginx
• Varnish — an HTTP accelerator focused on caching

Forward Proxies

Forward proxies are used on the client side for outgoing requests. In the context of DDoS protection, they are used less frequently but can be useful for:

• Hiding the IP addresses of your servers when accessing external APIs
• Distributing outgoing traffic through multiple IP addresses
• Bypassing blocks when gathering information about potential attacks

For these tasks, residential proxies are suitable — they have real IP addresses of home users and appear as regular traffic, making them harder to detect and block.

Setting Up a Reverse Proxy on Nginx for Server Protection

Nginx is one of the most popular tools for creating a reverse proxy. It quickly processes incoming requests, supports rate limiting, and can filter suspicious traffic.

Basic Configuration of a Reverse Proxy

Install Nginx on a separate server that will receive all incoming traffic. The real web server should be hidden behind the proxy and only accept requests from it.

# /etc/nginx/nginx.conf

http {
    # Limit the number of connections from a single IP
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
    limit_conn conn_limit 10;

    # Limit the number of requests (rate limiting)
    limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;
    limit_req zone=req_limit burst=20 nodelay;

    # Timeouts to protect against Slowloris
    client_body_timeout 10s;
    client_header_timeout 10s;
    keepalive_timeout 5s 5s;
    send_timeout 10s;

    upstream backend {
        # IP of your real web server
        server 192.168.1.100:80;
        # You can add multiple servers for load balancing
        # server 192.168.1.101:80;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            # Forward requests to backend
            proxy_pass http://backend;
            
            # Forward the original client IP
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $host;
            
            # Timeouts for the proxy
            proxy_connect_timeout 5s;
            proxy_send_timeout 10s;
            proxy_read_timeout 10s;
        }
    }
}

Blocking Suspicious User-Agents

Many DDoS attacks use bots with characteristic User-Agents. Add rules to block them:

# Block known bots
map $http_user_agent $bad_bot {
    default 0;
    ~*bot 1;
    ~*crawler 1;
    ~*spider 1;
    ~*scraper 1;
    "" 1; # Empty User-Agent
}

server {
    listen 80;
    server_name example.com;

    if ($bad_bot) {
        return 403;
    }

    location / {
        proxy_pass http://backend;
    }
}

Geo-blocking Unwanted Countries

If your service operates only for certain countries, you can block traffic from other regions using the GeoIP module:

# Install the GeoIP module
# apt-get install nginx-module-geoip

load_module modules/ngx_http_geoip_module.so;

http {
    geoip_country /usr/share/GeoIP/GeoIP.dat;

    # Allow only traffic from Russia and Ukraine
    map $geoip_country_code $allowed_country {
        default no;
        RU yes;
        UA yes;
    }

    server {
        listen 80;
        server_name example.com;

        if ($allowed_country = no) {
            return 403;
        }

        location / {
            proxy_pass http://backend;
        }
    }
}

HAProxy for Load Balancing and Traffic Filtering

HAProxy is a powerful load balancer with advanced traffic filtering capabilities. It supports complex ACLs (Access Control Lists) for blocking application-level attacks.

Basic HAProxy Configuration

# /etc/haproxy/haproxy.cfg

global
    maxconn 50000
    # Logging
    log /dev/log local0
    log /dev/log local1 notice

defaults
    mode http
    log global
    option httplog
    option dontlognull
    
    # Timeouts
    timeout connect 5s
    timeout client 30s
    timeout server 30s
    
    # Limit request size (protection against POST flood)
    maxconn 3000

frontend http_front
    bind *:80
    
    # Rate limiting: maximum 100 requests in 10 seconds from a single IP
    stick-table type ip size 100k expire 30s store http_req_rate(10s)
    http-request track-sc0 src
    http-request deny if { sc_http_req_rate(0) gt 100 }
    
    # Block requests without Host header
    acl has_host hdr(host) -m found
    http-request deny if !has_host
    
    # Block suspicious User-Agents
    acl bad_bot hdr_sub(User-Agent) -i bot crawler spider scraper
    http-request deny if bad_bot
    
    # Forward to backend
    default_backend web_servers

backend web_servers
    balance roundrobin
    option httpchk GET /health
    
    # List of backend servers
    server web1 192.168.1.100:80 check
    server web2 192.168.1.101:80 check
    server web3 192.168.1.102:80 check

Protection Against HTTP Flood Using ACL

HTTP Flood is an attack where an attacker sends a multitude of legitimate HTTP requests. HAProxy allows you to create complex rules to detect them:

frontend http_front
    bind *:80
    
    # Tracking the number of requests from a single IP
    stick-table type ip size 100k expire 30s store http_req_rate(10s),conn_cur
    http-request track-sc0 src
    
    # Blocking when limits are exceeded
    acl too_many_requests sc_http_req_rate(0) gt 50
    acl too_many_connections sc_conn_cur(0) gt 10
    
    http-request deny deny_status 429 if too_many_requests
    http-request deny deny_status 429 if too_many_connections
    
    # Blocking requests to non-existent paths (scanning)
    acl valid_path path_beg /api /static /login /
    http-request deny if !valid_path
    
    default_backend web_servers

Whitelist Trusted IP Addresses

Create a whitelist for trusted IPs (e.g., your office addresses or partners) that will not be subject to rate limiting:

frontend http_front
    bind *:80
    
    # Whitelist of trusted IPs
    acl whitelist src 203.0.113.0/24 198.51.100.50
    
    # Rate limiting only for non-whitelist IPs
    stick-table type ip size 100k expire 30s store http_req_rate(10s)
    http-request track-sc0 src if !whitelist
    http-request deny if { sc_http_req_rate(0) gt 100 } !whitelist
    
    default_backend web_servers

Using Residential Proxies to Hide Infrastructure

In addition to reverse proxies in front of your server, you can use residential proxies for additional protection of your infrastructure. This is especially relevant if you need to:

• Hide the IP addresses of your monitoring servers — if you are monitoring DDoS attacks or gathering threat information, residential proxies will help conceal your actions
• Access external APIs without revealing infrastructure — your servers can make requests through residential proxies, making them harder to detect
• Test DDoS protection — simulate attacks from different IP addresses to check the effectiveness of your filters

Residential proxies have the IP addresses of real home users, making them indistinguishable from regular traffic. This complicates their blocking and allows bypassing geo-restrictions.

Example: Threat Monitoring via Residential Proxies

Suppose you want to monitor botnet activity that may attack your service. By using residential proxies, you can gather information without revealing your server's IP addresses:

import requests

# Setting up a residential proxy
proxies = {
    'http': 'http://username:password@residential-proxy.com:8080',
    'https': 'http://username:password@residential-proxy.com:8080'
}

# Gathering information about potential threats
threat_sources = [
    'http://suspicious-site1.com',
    'http://suspicious-site2.com'
]

for source in threat_sources:
    try:
        response = requests.get(source, proxies=proxies, timeout=5)
        # Analyzing the response to identify attack patterns
        print(f"Status: {response.status_code}, IP: {response.headers.get('X-Your-IP')}")
    except Exception as e:
        print(f"Error accessing {source}: {e}")

Filtering Rules: How to Distinguish an Attack from Legitimate Traffic

The main difficulty in protecting against DDoS at the application level (L7) is distinguishing malicious traffic from legitimate traffic. Modern attacks mimic the behavior of real users, making them hard to detect.

Signs of a DDoS Attack

• Sharp increase in the number of requests — 2-10 times more than usual over a short period
• Requests with the same User-Agent — bots often use the same User-Agent
• Absence of Referer — direct requests without coming from other pages
• Homogeneous requests — requests to the same URL with minimal variations
• Absence of JavaScript — bots do not execute JS code on the page
• Low time on page — bots immediately close the connection after receiving a response
• Suspicious IP ranges — mass requests from a single subnet

Multi-layer Filtering

Effective protection uses multiple layers of filtering:

Example: JavaScript Challenge in Nginx

A simple way to filter bots is to require JavaScript execution to set a cookie:

server {
    listen 80;
    server_name example.com;

    # Check for cookie presence
    set $has_cookie 0;
    if ($http_cookie ~* "verified=true") {
        set $has_cookie 1;
    }

    # If cookie is absent, show JS challenge
    location / {
        if ($has_cookie = 0) {
            return 200 '
                <html>
                <head><title>Verification</title></head>
                <body>
                <script>
                    document.cookie = "verified=true; path=/";
                    window.location.reload();
                </script>
                <noscript>Please enable JavaScript</noscript>
                </body>
                </html>
            ';
        }

        proxy_pass http://backend;
    }
}

Monitoring and Responding to DDoS in Real Time

Effective DDoS protection requires constant traffic monitoring and rapid response to anomalies. Set up a monitoring system that tracks key metrics:

• Requests per second — a sharp increase may indicate an attack
• Number of unique IP addresses — DDoS often comes from many IPs
• Percentage of 4xx/5xx errors — an increase in errors may be a sign of overload
• Server response time — increased latency indicates problems
• Resource consumption — CPU, memory, network traffic

Monitoring Tools

Setting Up Alerts in Prometheus

Create rules for automatic alerts upon detecting anomalies:

# prometheus_alerts.yml

groups:
  - name: ddos_detection
    interval: 10s
    rules:
      # Alert on sharp increase in requests
      - alert: HighRequestRate
        expr: rate(nginx_http_requests_total[1m]) > 1000
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "High request rate detected"
          description: "Request rate is {{ $value }} req/s"

      # Alert on increase in 5xx errors
      - alert: HighErrorRate
        expr: rate(nginx_http_requests_total{status=~"5.."}[5m]) > 10
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "High 5xx error rate"
          description: "5xx errors: {{ $value }} req/s"

      # Alert on high CPU usage
      - alert: HighCPUUsage
        expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High CPU usage"
          description: "CPU usage is {{ $value }}%"

Automatic Response with Fail2ban

Fail2ban analyzes logs and automatically blocks IP addresses that exceed request limits:

# /etc/fail2ban/jail.local

[nginx-req-limit]
enabled = true
filter = nginx-req-limit
logpath = /var/log/nginx/access.log
maxretry = 100
findtime = 60
bantime = 3600
action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]

# /etc/fail2ban/filter.d/nginx-req-limit.conf
[Definition]
failregex = ^<HOST> -.*"(GET|POST).*HTTP.*"
ignoreregex =

Multi-layer Protection: Combining Proxies with Other Methods

Proxy servers are an important element of DDoS protection, but they are most effective when combined with other methods. Let's consider the architecture of multi-layer protection:

Level 1: Network Protection (L3/L4)

• Cloud anti-DDoS services — Cloudflare, AWS Shield, Google Cloud Armor filter traffic before it reaches your servers
• Hardware firewalls — specialized equipment for filtering network traffic
• BGP blackholing — redirecting malicious traffic to a "black hole" at the provider level

Level 2: CDN and Caching

• CDN (Content Delivery Network) — distributes static content across multiple servers, reducing the load on the origin
• Caching on proxies — Varnish, Nginx cache popular pages and serve them without contacting the backend
• Content optimization — minification of CSS/JS, image compression reduces traffic volume

Level 3: Proxies and Load Balancing (L7)

• Reverse proxies — Nginx, HAProxy filter requests at the application level
• Load balancing — distributing load among multiple backend servers
• Rate limiting — limiting the number of requests from a single IP
• WAF (Web Application Firewall) — ModSecurity, AWS WAF block attacks on web applications

Level 4: Backend Optimization

• Database optimization — indexes, query caching, read replicas
• Asynchronous processing — heavy tasks are performed in the background via queues (RabbitMQ, Redis)
• Horizontal scaling — adding new servers as load increases

Example Architecture

Client
  ↓
Cloudflare (anti-DDoS L3/L4, CDN)
  ↓
Nginx reverse proxy (rate limiting, filtering)
  ↓
HAProxy (load balancing)
  ↓
Backend servers (web application)
  ↓
Database (with replication)

This architecture provides protection at all levels: network, transport, application. Even if an attack passes one level, the next will stop it.

Using Datacenter Proxies for Additional Layer

In some cases, it makes sense to add datacenter proxies as an intermediate layer between the CDN and your servers. They provide high processing speed and can perform additional traffic filtering. Datacenter proxies are cheaper than residential and mobile ones, making them a cost-effective solution for handling large volumes of traffic.

Conclusion

Protecting against DDoS attacks using proxy servers is an effective method that allows filtering malicious traffic, hiding the real IP addresses of servers, and distributing load. Reverse proxies based on Nginx or HAProxy provide flexible configuration of filtering rules, rate limiting, and blocking suspicious requests.

Key points we covered:

• Reverse proxies (Nginx, HAProxy) are the main tool for application-level protection (L7)
• Rate limiting and filtering by User-Agent, IP reputation help filter out most attacks
• Residential proxies are useful for hiding monitoring infrastructure and gathering threat information
• Multi-layer protection (CDN + proxies + WAF + backend optimization) provides maximum resilience
• Monitoring and automatic response are critically important for quick detection and blocking of attacks

Remember that DDoS attacks are constantly evolving, so your protection system requires regular updates and testing. Conduct load testing, analyze logs, update filtering rules, and stay informed about new attack methods.

If you plan to build a multi-layer protection system using proxies, we recommend considering residential proxies to hide critical infrastructure and datacenter proxies for high-speed processing of large volumes of traffic. Combining different types of proxies provides an optimal balance between security, performance, and cost.