Securing a V2Ray server involves more than choosing a robust protocol — it requires precise firewall configuration, careful port management, and layered defenses to reduce attack surface and prevent abuse. This article provides practical, actionable rules and examples for iptables, nftables, UFW, and firewalld, and shows how to combine rate limiting, port obfuscation, and other hardening techniques to protect your V2Ray (or Xray) deployment in production.

Understand the attack surface

Before hardening, enumerate what must be reachable and what can be denied. A typical V2Ray server exposes:

  • One or more listener ports for V2Ray inbound protocols (VMess, VLESS, Trojan, etc.).
  • Optional ports for management (SSH), monitoring, or other services (HTTP/HTTPS for web, port 53 for DNS in some setups).
  • Outgoing connections from the server (for relays, DNS, or remote logging).

Minimize open ports: only expose the V2Ray inbound port(s) and essential services like SSH. All other ports should be blocked by default.

Network principles to apply

Apply these principles consistently across firewall tools:

  • Default deny incoming: block all inbound traffic except explicitly allowed ports.
  • Limit outgoing if possible: restrict outbound traffic to required destinations and protocols (egress filtering).
  • Use stateful rules: permit established/related connections to reduce rule set complexity.
  • Rate limit and fail2ban: throttle suspicious connection patterns (SSH, V2Ray handshake floods).
  • Bind to specific IPs: have V2Ray listen only on the public IP you intend to use rather than 0.0.0.0 when possible.

iptables examples (legacy systems)

Below are practical iptables rules for a typical Linux server. Adjust interface names and ports as needed. These assume IPv4; replicate for IPv6 if used.

Baseline rules:

iptables -F
iptables -X
iptables -t nat -F
iptables -t mangle -F
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT


Allow loopback

iptables -A INPUT -i lo -j ACCEPT


Allow established/related

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT


Allow SSH (adjust port if nonstandard)

iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m limit --limit 25/minute --limit-burst 100 -j ACCEPT


Allow V2Ray TCP inbound (example port 443)

iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT


If V2Ray uses UDP (eg mKCP)

iptables -A INPUT -p udp --dport 443 -m conntrack --ctstate NEW -j ACCEPT


Drop invalid packets

iptables -A INPUT -m conntrack --ctstate INVALID -j DROP


Log and drop everything else (optional)

iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables-drop: "
iptables -A INPUT -j DROP

Notes:

  • Replace port 443 with your chosen port. Using 443 can help bypass some filters but increases scrutiny; running on a high random port reduces noise.
  • Use a nonstandard SSH port or limit SSH by source IP where possible to reduce brute-force attacks.

nftables examples (modern kernels)

nftables replaces iptables on many distributions. Example config:

nft add table inet filter
nft 'add chain inet filter input { type filter hook input priority 0; policy drop; }'
nft add chain inet filter output { type filter hook output priority 0; policy accept; }
nft add chain inet filter forward { type filter hook forward priority 0; policy drop; }


Allow loopback

nft add rule inet filter input iif lo accept


Allow established

nft add rule inet filter input ct state established,related accept


Allow SSH (nonstandard port recommended)

nft add rule inet filter input tcp dport 22 ct state new limit rate 25/second accept


Allow V2Ray TCP & UDP

nft add rule inet filter input tcp dport 443 ct state new accept
nft add rule inet filter input udp dport 443 ct state new accept


Drop invalid

nft add rule inet filter input ct state invalid drop

UFW and firewalld (user-friendly frontends)

If you use Ubuntu or systems with ufw or CentOS/RHEL with firewalld, use these concise commands:

UFW example:

ufw default deny incoming
ufw default allow outgoing
ufw allow ssh/tcp
ufw allow 443/tcp
ufw allow 443/udp   # if V2Ray uses UDP
ufw enable

firewalld example:

firewall-cmd --permanent --set-default-zone=drop
firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=443/udp
firewall-cmd --reload

Advanced techniques: port obfuscation and multiplexing

To reduce detection and automated attacks, consider the following:

  • Port randomization: use a high ephemeral port (eg 15000–65000) instead of common ports. This reduces scanning noise.
  • TLS + WebSocket (WS over TLS): configure V2Ray to use TLS with WebSocket and host it behind a legitimate-looking website. This helps it blend into normal HTTPS traffic.
  • SNI and ALPN mimicry: set SNI to a real domain and configure ALPN to include “h2” or “http/1.1” to look like regular web clients.
  • Using reverse proxy (Nginx/Caddy): terminate TLS at a reverse proxy and proxy_pass to V2Ray local port. This allows easier certificate management and HTTP header masking.

Nginx reverse proxy example (snippet)

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location /ray {
        proxy_redirect off;
        proxy_pass http://127.0.0.1:10085;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;
    }
}

Then configure V2Ray to listen on 127.0.0.1:10085 (no external exposure).

Bind to local interfaces and use loopback proxies

Whenever possible, have V2Ray listen on localhost and expose only the proxying TLS endpoint (eg Nginx) on the public interface. This isolates the V2Ray process from direct internet access and simplifies firewall rules:

  • Nginx handles TLS and HTTP/WS, listening on public IP:443.
  • V2Ray listens on 127.0.0.1:PORT and is reachable only locally.
  • Firewall only needs to allow 443/tcp to the public interface; 127.0.0.1 ports are inaccessible externally.

Rate limiting and connection control

Prevent abuse such as handshake floods by rate limiting at the firewall or web server level.

  • iptables example: use the recent module to limit new connections per IP.
  • Nginx: limit_conn_zone and limit_req_zone can control concurrent connections and request rates for WS endpoints.
  • Use fail2ban to monitor logs (SSH, Nginx, V2Ray log) and ban IPs with repeated failures.

Example iptables recent rule to limit new connections to 10 per minute:

iptables -N RATE-LIMIT
iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -j RATE-LIMIT
iptables -A RATE-LIMIT -m recent --set --name v2ray
iptables -A RATE-LIMIT -m recent --update --seconds 60 --hitcount 10 --rttl --name v2ray -j DROP
iptables -A RATE-LIMIT -j ACCEPT

Fail2ban: automated banning

Configure fail2ban to parse V2Ray/Nginx logs. Example jail for Nginx proxy logs:

[nginx-ratelimit]
enabled = true
filter = nginx-ratelimit
action = iptables[name=NGINX, port=443, protocol=tcp]
logpath = /var/log/nginx/access.log
maxretry = 10
bantime = 3600

Create a custom filter to detect too many handshake errors, 444 responses, or suspicious WebSocket connection patterns.

Logging, monitoring, and alerting

Maintain meaningful logs while avoiding exposure of sensitive keys. Centralize logs and monitor:

  • Conntrack/iptables drop counters to detect scanning spikes.
  • Nginx access logs for unusual User-Agent or request rates.
  • V2Ray access/error logs for frequent authentication failures.

Set up alerts for repeated dropped packets or a sudden surge in connection attempts which might indicate an ongoing scan or DDoS. Consider using tools like Prometheus + Grafana for metrics visualization.

IP whitelisting, geo-blocking, and egress controls

For enterprise environments:

  • Whitelist known client IPs to reduce surface area (especially for management ports).
  • Use geo-blocking if your user base is limited to certain regions, though this is not foolproof against proxies.
  • Limit outbound connections to only necessary destinations (DNS servers, syslog endpoints) to prevent compromised services from being used as pivot points.

Operational checklist before going live

  • Ensure only necessary public ports are open; verify with nmap from an external host.
  • Use a non-default V2Ray ID and strong keys/configuration.
  • Run V2Ray on a non-root user; set file permissions for config files and certificates.
  • Deploy automatic certificate renewal (Let’s Encrypt) and ensure firewall rules accommodate ACME challenges if using HTTP challenge.
  • Test failover and logging; ensure you can recover access (console/IPMI) if firewall locks you out.

Combining firewall policies with port obfuscation, reverse proxying, rate limiting, and monitoring provides a robust defense in depth for a V2Ray server. Tailor rules to your infrastructure and iterate based on observed traffic patterns.

For additional guidance, examples, and managed solutions tailored to running secure, stable V2Ray/Xray servers, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.