This post serves as a living document for diagnosing and resolving various V2Ray/VLESS configuration and connection issues.

Case 1: WebSocket Close 1000 (Time Synchronization)

Date: 2025-11-11
Issue: Ubuntu client fails to connect while Mac client works with identical config.

1.1 The Scenario

  • Device A (Failing): Ubuntu 20.04 physical machine (Gateway/Service mode).
  • Device B (Working): Mac Mini on the same subnet.
  • Protocol: VLESS + WebSocket + TLS.
  • Symptom: Apps utilizing the Ubuntu proxy failed to connect.

1.2 The Error Log

Checking the logs on the Ubuntu machine revealed the following error repeatedly:

2025/11/11 06:10:02 [Warning] v2ray.com/core: V2Ray 4.31.0 started
2025/11/11 15:03:22 [Warning] [442700300] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vless/outbound: connection ends > v2ray.com/core/proxy/vless/outbound: failed to decode response header > v2ray.com/core/proxy/vless/encoding: failed to read response version > websocket: close 1000 (normal)

1.3 Analysis

The key indicator here is websocket: close 1000 (normal).

  1. Connectivity is fine: The client did reach the server.
  2. Server Rejection: The code 1000 (normal) implies the server side actively closed the connection immediately after the handshake, rather than a network timeout or firewall drop.
  3. Environment Specific: Since the Mac worked with the exact same UUID and Config, the issue was isolated to the Ubuntu environment itself.

1.4 The Solution

The issue was resolved by synchronizing the system time and restarting the service. Even a deviation of a few seconds can sometimes cause handshake issues depending on the transport layer.

Step 1: Check & Sync Time
On the failing Ubuntu machine:

# Check current time  
date

# Force synchronization (requires ntpdate)  
sudo apt install ntpdate  
sudo ntpdate pool.ntp.org

Step 2: Restart the Service
This is the critical step. Syncing time alone might not clear stuck socket states.

sudo systemctl restart v2ray.service

After these steps, the connection was immediately restored.

1.5 The Technical “Why”

You might wonder: VLESS is technically a stateless protocol (unlike VMess), so why does a few seconds of time drift matter?

There are two factors at play here:

  1. TLS & CDN Sensitivity: While VLESS itself might accept the connection, the underlying TLS handshake or the CDN (if you are routing through Cloudflare, etc.) can be strict. If the client timestamp drifts, the handshake might be flagged as an invalid or replay attack attempt by the transport layer.
  2. The “Restart” Effect: In this specific case, the time drift was minimal (only a few seconds). It is highly likely that the Restart (systemctl restart) did the heavy lifting. The V2Ray Core (especially older versions like v4.31) can sometimes accumulate “zombie” connections or get stuck in a bad state. Restarting the service clears the connection pool and forces a fresh handshake with the corrected time.

Case 2: [Placeholder for Future Issues]

(To be added when the next bug appears…)