Traffic shaping and bandwidth limiting are essential tools for administrators running V2Ray-based services who need to guarantee predictable performance, enforce fair use policies, or protect backend infrastructure from overload. While V2Ray provides flexible routing and multiplexing options, most robust bandwidth control is implemented at the network stack level. This article walks through practical techniques — from V2Ray configuration tips to system-level shaping using tc, iptables/nftables, cgroups and monitoring — so site operators, developers and enterprise administrators can design a controlled, performant V2Ray deployment.

Why combine V2Ray features with OS-level shaping?

V2Ray offers application-layer features that affect throughput and latency: connection multiplexing (mux), different transport protocols (TCP, mKCP, WebSocket, HTTP/2, QUIC), and routing/balancer policies. These tools help with connection efficiency and obfuscation, but they do not provide precise per-IP or per-user bandwidth quotas. For predictable limits and traffic prioritization you need to use the OS network stack — primarily tc (Traffic Control), optionally augmented by iptables/nftables marks, cgroups, and system-level tuning.

Key goals for an optimized deployment

  • Enforce per-client or per-service bandwidth caps
  • Prioritize latency-sensitive control plane traffic (DNS, TLS handshakes)
  • Limit bursts to protect upstream links and avoid packet loss
  • Monitor and adapt limits dynamically using metrics from V2Ray and system tools

Prepare V2Ray for shaping: configuration knobs that matter

Before shaping, tune V2Ray to produce traffic that is easier to manage:

  • Mux: Enable or tune "mux" in client and server. Fewer TCP sessions reduce per-connection overhead and simplify QoS classification because traffic aggregates into fewer flows. But excessive mux can cause head-of-line effects for latency-sensitive streams — choose a moderate concurrency limit.
  • Transport selection: TCP and WebSocket produce more uniform 5-tuple flows; UDP-based transports (mKCP, QUIC) are more bursty and may require different qdisc parameters. QUIC can be prioritized, but shaping UDP requires care to avoid impacting retransmission logic.
  • policy and stats: Enable V2Ray’s statistics and streaming policies. Use the stats API or Prometheus exporter to feed traffic volumes into your management/automation systems. Example: "stats": { "inbound": true, "outbound": true } in new versions.
  • connection limits: Use V2Ray’s policy settings to limit concurrent connections and idle time per user/level. This reduces excessive connection churn that complicates shaping.

Core technique: tc + iptables/nftables fwmark for granular shaping

Using tc with classful qdiscs like HTB or Hierarchical Token Bucket provides reliable rate limiting with guarantees and priorities. To apply rules per user, per IP, or per group of ports, attach fwmarks using iptables (or nftables) and let tc filters match on those marks.

Basic HTB setup (root qdisc)

# clear existing qdiscs
tc qdisc del dev eth0 root || true


root HTB

tc qdisc add dev eth0 root handle 1: htb default 30


high-priority class (guaranteed 10Mbps, ceil 20Mbps)

tc class add dev eth0 parent 1: classid 1:10 htb rate 10mbit ceil 20mbit burst 15kb


general class (default, 5Mbps)

tc class add dev eth0 parent 1: classid 1:30 htb rate 5mbit ceil 5mbit

Mark V2Ray traffic using iptables

Decide how to identify user flows. Options include source IP (for per-client limits), destination port (like port 443 or custom port), or user-specific outbound ports on your V2Ray server. Example: mark traffic arriving on port 443.

# mark incoming packets destined for V2Ray port 443
iptables -t mangle -A PREROUTING -p tcp --dport 443 -j MARK --set-mark 10


then in tc, match the mark

tc filter add dev eth0 parent 1: protocol ip prio 1 handle 10 fw flowid 1:10

For per-client shaping, match on source IP instead:

iptables -t mangle -A PREROUTING -s 203.0.113.45 -j MARK --set-mark 101
tc class add dev eth0 parent 1: classid 1:101 htb rate 2mbit ceil 2mbit
tc filter add dev eth0 parent 1: protocol ip handle 101 fw flowid 1:101

Advanced patterns: policing, bursting and latency control

HTB controls long-term rate, but for bursts and latency you can use TBF and netem in combination.

  • TBF (Token Bucket Filter) is great for limiting absolute peak rate and controlling burst size. Use it as a child qdisc on classes that need strict absolute caps.
  • netem can simulate or compensate for jitter/latency. In production you generally avoid adding latency, but netem’s loss/latency shaping is useful for testing or for smoothing UDP retransmission behavior in QUIC/mKCP flows.
# attach tbf to a class to limit bursts
tc qdisc add dev eth0 parent 1:101 handle 101: tbf rate 2mbit burst 32kbit latency 50ms

Per-process shaping: cgroups and net_cls

If your V2Ray server runs on the same host as other services, you can classify flows by process using cgroups v1 net_cls or cgroups v2 and systemd slices. Mark packets at the cgroup level then match those in tc.

# create a net_cls cgroup and set a classid
mkdir -p /sys/fs/cgroup/net_cls/v2ray
echo 0x10001 > /sys/fs/cgroup/net_cls/v2ray/net_cls.classid


launch v2ray under this cgroup (example with cgexec)

cgexec -g net_cls:v2ray /usr/bin/v2ray -config /etc/v2ray/config.json


tc filter matches classid

tc filter add dev eth0 parent 1: protocol ip prio 1 handle 1: cgroup

On systems using cgroups v2, use systemd slices to limit bandwidth with net_cls compatibility or rely on tc-based matching via pid-based iptables marking tools.

Rate-limiting connection behavior and protecting upstream

Traffic shaping is one part; you also want to control how V2Ray opens and maintains connections to avoid spikes:

  • Limit concurrency: Use V2Ray’s policy settings to cap concurrent outbound and inbound connections for lower levels/users.
  • Tune keepalive and idle: Reduce unnecessary idle connections with sensible connIdle and handshake timeouts.
  • Backpressure: If your upstream is saturated, prefer an HTB setup that uses ceilings to allow occasional bursting without collapsing latency-sensitive control flows.

Monitoring and feedback: keep visibility into shaping effectiveness

Visibility is critical. Combine V2Ray internal stats with system-level tools:

  • V2Ray stats API / Prometheus exporter for per-user, per-protocol metrics
  • iftop, bmon, nethogs for live bandwidth usage
  • vnStat for long-term usage
  • tc -s qdisc and tc -s class show for qdisc statistics

Automate reactions based on metrics: if a user exceeds quotas, automatically add iptables rules to throttle or redirect to a captive page; scale upstream resources when aggregate throughput approaches preset thresholds.

Kernel and network stack tuning

Shape behavior is also influenced by kernel settings. Some practical sysctl knobs:

  • net.core.somaxconn: Increase to allow more queued connections for busy servers.
  • net.ipv4.tcp_tw_reuse and tcp_fin_timeout: Tune to reduce TIME_WAIT buildup.
  • Enable modern congestion control (BBR) if supported: sysctl -w net.ipv4.tcp_congestion_control=bbr. BBR can improve throughput on high-latency paths.

Operational checklist and best practices

  • Start with application-level tuning (mux, transport) then layer in OS-level shaping.
  • Use fwmark-based classification for stable, reproducible tc filters.
  • Reserve a small high-priority class for control traffic (TLS handshakes, DNS) so connections don’t stall when link is saturated.
  • Test thoroughly with real client workloads (mix of small interactive streams and large bulk transfers) and monitor tail latencies and retransmits.
  • Automate rules rollback and use configuration management for tc/iptable rules to avoid lockout and ensure recoverability.

Example: end-to-end scenario

Imagine a V2Ray server on a 100 Mbps link serving multiple customers. You want to give each customer a 10 Mbps guaranteed allocation, allow occasional bursts to 20 Mbps, and reserve 5 Mbps for control traffic. Steps:

  • Create HTB root qdisc and classes for reserve and per-customer allocations.
  • Use iptables to mark packets by source IP (customer IP) or by port pair assigned to that customer.
  • Attach TBF to classes to limit bursts and netem only for testing.
  • Monitor with V2Ray stats + tc statistics, adjust class ceilings based on observed usage.

With these controls, you can enforce fair usage, avoid link saturation and improve overall user experience.

Conclusion: Combining V2Ray’s flexible transport and multiplexing options with robust OS-level traffic control delivers predictable, enforceable, and monitorable bandwidth limiting. Start with careful V2Ray tuning, classify flows via iptables/nftables or cgroups, and apply HTB/TBF to provide guarantees and control bursts. Finally, instrument the stack with metrics and automate responses so limits adapt safely to real-world traffic patterns.

For tools, examples and further configuration templates, see Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.