# Feature Request: Built-in latency-aware traffic queueing to reduce bufferbloat

[mustfqyl]

Summary

I would like to propose an optional, built-in traffic queueing / congestion-control mechanism in Xray-core designed to reduce bufferbloat and preserve low latency when an Xray server is under heavy traffic load.

This is not intended to be a per-user bandwidth limiting feature.

The goal is to allow all users to utilize available bandwidth normally, while preventing large transfers from creating excessive queues that negatively affect latency-sensitive traffic such as gaming, VoIP, DNS, interactive web browsing, remote desktop, and other real-time applications.

Problem

Consider an Xray server with a 1 Gbps uplink.

Under normal conditions, multiple users can share the link without problems. However, when one or more users start large downloads/uploads and the uplink becomes saturated, packets can accumulate in large queues.

For example:

User A → 600 Mbps download
User B → 300 Mbps download
User C → online game / VoIP
                 ↓
             1 Gbps uplink

Without effective queue management, the congestion can cause large increases in RTT even though the server still has enough processing capacity.

A latency-sensitive connection may go from:

10–20 ms → 100–500+ ms

simply because another connection is transferring a large amount of data.

This is particularly undesirable for VPN/proxy servers where many unrelated users share the same network interface.

Proposed Feature

Add an optional latency-aware traffic queueing mechanism to Xray-core.

Possible implementations could use or be inspired by algorithms such as:

• FQ-CoDel
• CAKE
• another fair-queueing / AQM algorithm suitable for Xray's architecture

The implementation does not necessarily need to reproduce Linux tc internally. If practical, Xray could expose an abstraction that provides similar queue-management behavior.

The important behavior would be:

1. No fixed per-user bandwidth limit

Users should not be assigned arbitrary bandwidth caps.

If the link is idle, a user should be able to use as much bandwidth as available.

2. Queue only when congestion occurs

When the link is not congested, traffic should behave normally.

When congestion begins, the queue manager should prevent excessive queue buildup.

3. Fairness between flows

Large bulk transfers should not be able to monopolize the queue.

Multiple concurrent flows should receive fair treatment without requiring manual bandwidth limits for each user.

4. Preserve low latency

Small and latency-sensitive packets should not have to wait behind large amounts of bulk traffic whenever this can be avoided.

The primary goal is to reduce queueing delay, not to maximize throughput at the expense of latency.

5. Support TCP and UDP

The mechanism should ideally work with both TCP and UDP traffic, since Xray deployments can carry latency-sensitive UDP traffic as well as traditional TCP traffic.

Why this would be useful for Xray

Xray is frequently used as a shared proxy/VPN gateway where many independent connections pass through the same server.

A built-in latency-aware queue would provide several benefits:

• Better gaming latency during heavy downloads
• More stable VoIP/video-call performance
• Better interactive browsing responsiveness
• Reduced latency spikes during server congestion
• More predictable performance on heavily loaded nodes
• Better coexistence between bulk transfers and real-time applications
• Less need for administrators to manually configure Linux tc rules around Xray

This could be particularly valuable for deployments where Xray is running directly on a VPS and the administrator does not want to maintain a separate traffic-management layer.

Example

With a 1 Gbps server:

                    Without AQM
                         │
          ┌──────────────┴──────────────┐
          │                             │
    Large download                Game traffic
       900 Mbps                      1 Mbps
          │                             │
          └───────────┬─────────────────┘
                      ↓
                Large queue
                      ↓
               RTT +300 ms

With latency-aware queue management:

                 Xray traffic
                      │
                      ↓
             Fair / AQM queue
                      │
          ┌───────────┴───────────┐
          │                       │
     Bulk transfers        Interactive traffic
          │                       │
          └───────────┬───────────┘
                      ↓
                   Uplink

The bulk transfer can still consume most of the available bandwidth, but it should no longer create unnecessarily large queues that cause severe latency spikes.

Configuration concept

Something conceptually similar to:

{
  "trafficManagement": {
    "enabled": true,
    "algorithm": "fq-codel",
    "targetLatency": "20ms",
    "interval": "100ms"
  }
}

The exact configuration and algorithm are of course open for discussion.

An even better implementation could automatically determine reasonable parameters based on the detected interface/uplink characteristics.

Important distinction

This feature is not intended to replace existing operating-system QoS mechanisms in every deployment.

Linux tc with CAKE/FQ-CoDel can already solve parts of this problem externally.

The motivation for considering support in Xray itself is that Xray already has knowledge of its traffic flows and sits directly in the path of the proxied traffic.

Having an optional Xray-level mechanism could make latency protection easier to deploy consistently across Xray nodes without requiring external traffic-control scripts and interface-specific configuration.

Expected result

The desired behavior is essentially:

Use all available bandwidth when possible, but when congestion occurs, sacrifice a small amount of peak throughput if necessary to avoid large queueing delays and preserve low latency.

This would make heavily loaded Xray servers significantly more responsive without requiring administrators to impose arbitrary bandwidth limits on users.

I believe this could be a useful optional feature for high-density Xray deployments and latency-sensitive VPN/proxy use cases.