← Quay lại blog
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

Hướng dẫn đầy đủ về việc sử dụng WebSocket qua proxy: cách proxy kết nối WS và WSS

Kết nối WebSocket hoạt động khác với các yêu cầu HTTP thông thường - và các proxy tiêu chuẩn thường ngắt kết nối chúng. Chúng ta sẽ tìm hiểu cách proxy đúng cách lưu lượng WS và WSS mà không làm mất kết nối.

📅7 tháng 8, 2026
```html

WebSocket không phải là một yêu cầu HTTP thông thường. Sau "bắt tay" ban đầu (handshake), kết nối vẫn mở và dữ liệu chảy theo cả hai hướng liên tục. Chính vì vậy, các proxy HTTP tiêu chuẩn thường làm gián đoạn các kết nối WS hoặc không thể xử lý chúng. Trong bài viết này, chúng ta sẽ tìm hiểu cách proxy hóa lưu lượng WebSocket một cách chính xác: loại proxy nào phù hợp, cách cấu hình chúng và những lỗi thường gặp.

WebSocket hoạt động như thế nào và tại sao nó khó khăn cho proxy

Để hiểu vấn đề, cần phải tìm hiểu về cơ chế. Kết nối WebSocket bắt đầu như một yêu cầu HTTP thông thường — khách hàng gửi tiêu đề Upgrade: websocket và Connection: Upgrade. Máy chủ phản hồi bằng mã 101 Switching Protocols — và từ thời điểm này, kết nối không còn là HTTP nữa. Nó trở thành một kênh hai chiều liên tục, nơi dữ liệu được truyền trong các khung.

Proxy HTTP/1.1 tiêu chuẩn, chỉ có khả năng chuyển tiếp yêu cầu và phản hồi, gặp phải vấn đề: nó không biết phải làm gì với kết nối sau khi nhận được phản hồi 101. Nhiều máy chủ proxy đơn giản là đóng kết nối vào thời điểm này hoặc trả về lỗi 502 Bad Gateway. Những máy chủ khác giữ kết nối nhưng không thể truyền tải các khung WebSocket một cách chính xác, dẫn đến việc ngắt quãng hoặc biến dạng dữ liệu.

Đây là những điểm khác biệt chính giữa WebSocket và HTTP thông thường từ góc độ proxy:

Tham số HTTP WebSocket
Loại kết nối Yêu cầu → Phản hồi → Đóng Liên tục, hai chiều
Thời gian sống Giây (một yêu cầu) Phút, giờ, ngày
Người khởi xướng dữ liệu Chỉ khách hàng Khách hàng và máy chủ
Giao thức sau khi bắt tay HTTP Riêng (RFC 6455)
Cổng 80, 443 80 (WS), 443 (WSS)

Chính vì sự thay đổi giao thức sau khi bắt tay mà hầu hết các giải pháp proxy đơn giản không thể xử lý WebSocket. Bạn cần phải sử dụng một proxy rõ ràng hỗ trợ việc tạo đường hầm hoặc sử dụng SOCKS5 — một giao thức hoạt động ở cấp độ thấp hơn và không phân tích nội dung lưu lượng.

Các loại proxy nào hỗ trợ WebSocket

Không phải tất cả các proxy đều hữu ích cho WebSocket. Chúng ta sẽ xem xét từng loại:

Loại proxy Hỗ trợ WS Cơ chế Độ phức tạp
Proxy HTTP ⚠️ Một phần Qua đường hầm CONNECT Trung bình
Proxy HTTPS ✅ Có CONNECT + TLS Trung bình
SOCKS4 ⚠️ Hạn chế Đường hầm TCP không có xác thực Thấp
SOCKS5 ✅ Hoàn toàn TCP/UDP trong suốt Thấp
Proxy trong suốt ❌ Không Chỉ HTTP —

Kết luận: cho các tác vụ WebSocket, lựa chọn tối ưu là SOCKS5. Giao thức này hoạt động ở cấp độ giao thông và chỉ đơn giản là tạo đường hầm cho kết nối TCP mà không cần quan tâm đến nội dung lưu lượng. Nó không quan tâm đến việc bên trong là HTTP, WebSocket, SSH hay bất cứ thứ gì khác. Proxy HTTP cũng có thể hoạt động với WS, nhưng chỉ thông qua phương thức CONNECT — và có những điểm cần lưu ý mà chúng ta sẽ thảo luận bên dưới.

Phương thức CONNECT: cách mà proxy HTTP tạo đường hầm cho WebSocket

Phương thức HTTP CONNECT — là một cơ chế đặc biệt cho phép proxy HTTP tạo ra một đường hầm "mù" đến máy chủ đích. Proxy không phân tích lưu lượng bên trong đường hầm, mà chỉ đơn giản là chuyển tiếp các byte. Đây là cách mà HTTPS hoạt động qua proxy HTTP — và đây cũng là cách để proxy hóa WebSocket.

Quá trình diễn ra như sau:

  1. Khách hàng gửi yêu cầu đến proxy: CONNECT example.com:443 HTTP/1.1
  2. Proxy thiết lập kết nối TCP với example.com:443
  3. Proxy phản hồi cho khách hàng: 200 Connection Established
  4. Từ thời điểm này, proxy chỉ đơn giản là chuyển tiếp các byte qua lại — không phân tích chúng
  5. Khách hàng thực hiện TLS-handshake trực tiếp với máy chủ qua đường hầm
  6. Tiếp theo — WebSocket-handshake trên TLS

Giới hạn chính: phương thức CONNECT thường chỉ được phép cho cổng 443. Nếu máy chủ WebSocket của bạn hoạt động trên cổng không chuẩn (ví dụ, 8080 hoặc 9000), proxy có thể từ chối kết nối. Trong trường hợp này, SOCKS5 là lựa chọn ưu tiên hơn — nó không có giới hạn về cổng.

Cũng cần lưu ý rằng một số proxy HTTP doanh nghiệp (ví dụ, Squid trong cấu hình tiêu chuẩn) rõ ràng chặn phương thức CONNECT cho một số cổng nhất định hoặc yêu cầu xác thực. Nếu bạn làm việc với các nhà cung cấp proxy thương mại, hầu hết trong số họ hỗ trợ CONNECT mà không có giới hạn. 

# Ví dụ yêu cầu CONNECT qua curl (để kiểm tra)
curl -v -x http://proxy_host:proxy_port \
  --proxytunnel \
  https://echo.websocket.org

# Nếu proxy hỗ trợ CONNECT — bạn sẽ thấy:
# * CONNECT tunnel established, response 200

SOCKS5 và WebSocket: tại sao đây là lựa chọn tốt nhất

SOCKS5 là một giao thức proxy ở cấp độ TCP/UDP. Khác với proxy HTTP, SOCKS5 không biết gì về giao thức ứng dụng bên trong. Nó chỉ đơn giản tạo ra một đường hầm giữa khách hàng và máy chủ đích, và thôi. Điều này làm cho nó trở thành lựa chọn lý tưởng cho WebSocket vì một số lý do:

  • Không có giới hạn về giao thức: SOCKS5 tạo đường hầm cho bất kỳ lưu lượng TCP nào, bao gồm WS, WSS, SSH, FTP, v.v.
  • Không có giới hạn về cổng: hoạt động với bất kỳ cổng nào, không chỉ 443 hoặc 80
  • Không bị ngắt quãng khi thay đổi giao thức: proxy không "nhìn thấy" sự chuyển đổi từ HTTP sang WebSocket
  • Hỗ trợ xác thực: SOCKS5 hỗ trợ tên đăng nhập/mật khẩu, điều này thuận tiện cho các proxy thương mại
  • Hỗ trợ UDP: nếu ứng dụng của bạn sử dụng WebRTC hoặc UDP bên cạnh WS — SOCKS5 sẽ xử lý tốt

Hầu hết tất cả các thư viện hiện đại để làm việc với WebSocket đều hỗ trợ SOCKS5, trực tiếp hoặc thông qua các gói bổ sung. Dưới đây là một số ví dụ cụ thể cho Python và Node.js.

💡 Khi nào nên chọn SOCKS5, khi nào nên chọn HTTP CONNECT?

Sử dụng SOCKS5, nếu: cổng không chuẩn, cần hỗ trợ UDP, muốn tối thiểu hóa cấu hình.
Sử dụng HTTP CONNECT, nếu: nhà cung cấp proxy không hỗ trợ SOCKS5, hoặc bạn làm việc qua proxy doanh nghiệp.

Ví dụ mã: WebSocket qua proxy trên Python

Hãy xem xét một số kịch bản cho Python. Các thư viện phổ biến nhất cho WebSocket trong Python là websockets và websocket-client.

Tùy chọn 1: websocket-client qua proxy HTTP

import websocket

# Cấu hình proxy HTTP
proxy_host = "proxy.example.com"
proxy_port = 8080
proxy_user = "username"
proxy_pass = "password"

ws = websocket.WebSocket()

ws.connect(
    "wss://echo.websocket.org",
    http_proxy_host=proxy_host,
    http_proxy_port=proxy_port,
    http_proxy_auth=(proxy_user, proxy_pass),
    proxy_type="http"  # hoặc "socks5"
)

ws.send("Xin chào, WebSocket!")
result = ws.recv()
print(f"Nhận được: {result}")

ws.close()

Tùy chọn 2: websocket-client qua SOCKS5

import websocket

# Đối với SOCKS5 cần gói: pip install PySocks
ws = websocket.WebSocket()

ws.connect(
    "wss://echo.websocket.org",
    http_proxy_host="socks5_proxy.example.com",
    http_proxy_port=1080,
    http_proxy_auth=("username", "password"),
    proxy_type="socks5"
)

ws.send("Tin nhắn thử nghiệm")
print(ws.recv())
ws.close()

Tùy chọn 3: thư viện websockets (asyncio) qua SOCKS5

Thư viện websockets (asyncio) không có hỗ trợ tích hợp cho proxy, vì vậy chúng ta sử dụng python-socks để tạo đường hầm: 

# pip install websockets python-socks[asyncio]
import asyncio
import websockets
from python_socks.async_.asyncio import Proxy

async def connect_via_socks5():
    proxy = Proxy.from_url("socks5://username:[email protected]:1080")
    
    # Tạo kết nối TCP qua proxy
    sock = await proxy.connect(
        dest_host="echo.websocket.org",
        dest_port=443
    )
    
    # Chuyển socket vào websockets
    async with websockets.connect(
        "wss://echo.websocket.org",
        sock=sock
    ) as ws:
        await ws.send("Xin chào qua SOCKS5!")
        response = await ws.recv()
        print(f"Phản hồi: {response}")

asyncio.run(connect_via_socks5())

Tùy chọn 4: vá toàn cầu qua PySocks

Nếu bạn muốn định hướng toàn bộ lưu lượng của ứng dụng Python qua SOCKS5 mà không cần thay đổi từng lời gọi — hãy sử dụng socks.setdefaultproxy(): 

# pip install PySocks
import socks
import socket
import websocket

# Vá socket toàn cầu
socks.set_default_proxy(
    socks.SOCKS5,
    "proxy.example.com",
    1080,
    username="user",
    password="pass"
)
socket.socket = socks.socksocket

# Bây giờ tất cả các kết nối đều đi qua SOCKS5
ws = websocket.WebSocket()
ws.connect("wss://echo.websocket.org")
ws.send("Proxy SOCKS5 toàn cầu!")
print(ws.recv())
ws.close()

Ví dụ mã: WebSocket qua proxy trên Node.js

Trong hệ sinh thái Node.js, thư viện phổ biến nhất cho WebSocket là ws. Để proxy hóa qua HTTP/SOCKS5, sử dụng gói https-proxy-agent hoặc socks-proxy-agent.

Tùy chọn 1: WSS qua proxy HTTP CONNECT

// npm install ws https-proxy-agent
const WebSocket = require('ws');
const { HttpsProxyAgent } = require('https-proxy-agent');

const proxyUrl = 'http://username:[email protected]:8080';
const agent = new HttpsProxyAgent(proxyUrl);

const ws = new WebSocket('wss://echo.websocket.org', { agent });

ws.on('open', () => {
  console.log('Kết nối đã được thiết lập qua proxy HTTP');
  ws.send('Xin chào từ Node.js!');
});

ws.on('message', (data) => {
  console.log(`Nhận được: ${data}`);
  ws.close();
});

ws.on('error', (err) => {
  console.error('Lỗi:', err.message);
});

Tùy chọn 2: WSS qua SOCKS5

// npm install ws socks-proxy-agent
const WebSocket = require('ws');
const { SocksProxyAgent } = require('socks-proxy-agent');

const proxyUrl = 'socks5://username:[email protected]:1080';
const agent = new SocksProxyAgent(proxyUrl);

const ws = new WebSocket('wss://echo.websocket.org', { agent });

ws.on('open', () => {
  console.log('Kết nối qua SOCKS5 đã được thiết lập');
  ws.send(JSON.stringify({ type: 'ping', data: 'test' }));
});

ws.on('message', (data) => {
  console.log('Phản hồi:', data.toString());
});

ws.on('close', (code, reason) => {
  console.log(`Đã đóng: ${code} - ${reason}`);
});

Tùy chọn 3: WS (không có TLS) qua proxy HTTP thủ công

Đối với WS không mã hóa (cổng 80) qua proxy HTTP, cần phải gửi yêu cầu CONNECT thủ công, vì các đại lý tiêu chuẩn thường chỉ hoạt động với HTTPS: 

const net = require('net');
const WebSocket = require('ws');

function createTunnel(proxyHost, proxyPort, targetHost, targetPort) {
  return new Promise((resolve, reject) => {
    const socket = net.connect(proxyPort, proxyHost, () => {
      const connectReq = 
        `CONNECT ${targetHost}:${targetPort} HTTP/1.1\r\n` +
        `Host: ${targetHost}:${targetPort}\r\n` +
        `Proxy-Authorization: Basic ${Buffer.from('user:pass').toString('base64')}\r\n` +
        `\r\n`;
      
      socket.write(connectReq);
    });

    socket.once('data', (data) => {
      if (data.toString().includes('200')) {
        resolve(socket);
      } else {
        reject(new Error(`Proxy từ chối CONNECT: ${data.toString()}`));
      }
    });

    socket.on('error', reject);
  });
}

async function main() {
  const socket = await createTunnel(
    'proxy.example.com', 8080,
    'echo.websocket.org', 80
  );

  const ws = new WebSocket('ws://echo.websocket.org', { socket });
  
  ws.on('open', () => {
    ws.send('Đường hầm CONNECT thủ công!');
  });

  ws.on('message', (data) => {
    console.log('Nhận được:', data.toString());
    ws.close();
  });
}

main().catch(console.error);

WSS (WebSocket Secure): đặc điểm của việc proxy với TLS

WSS là WebSocket trên TLS (tương tự như HTTPS cho HTTP). Khi proxy hóa WSS qua SOCKS5 hoặc HTTP CONNECT, có một điểm quan trọng: Mã hóa TLS được thiết lập giữa khách hàng và máy chủ cuối, không phải giữa khách hàng và proxy. Điều này có nghĩa là:

  • Máy chủ proxy không thấy nội dung của lưu lượng WSS — chỉ thấy địa chỉ IP và cổng đích
  • Chứng chỉ của máy chủ được kiểm tra trực tiếp bởi khách hàng
  • Proxy không thể "thay thế" hoặc "chặn" dữ liệu mà không cài đặt chứng chỉ CA riêng

Đây là tin tốt từ góc độ bảo mật. Nhưng cũng có những điểm thực tiễn cần lưu ý khi cấu hình:

Kiểm tra chứng chỉ qua proxy

Đôi khi khi sử dụng các proxy doanh nghiệp (các proxy thực hiện kiểm tra SSL), bạn có thể nhận được lỗi kiểm tra chứng chỉ. Trong trường hợp này, proxy thay thế chứng chỉ của máy chủ bằng chứng chỉ của nó. Để hoạt động trong môi trường như vậy, cần thêm chứng chỉ CA của proxy vào danh sách tin cậy: 

# Python: truyền chứng chỉ CA của proxy doanh nghiệp
import ssl
import websocket

ssl_context = ssl.create_default_context()
ssl_context.load_verify_locations("/path/to/corporate-ca.crt")

ws = websocket.WebSocket(sslopt={"context": ssl_context})
ws.connect(
    "wss://internal.example.com",
    http_proxy_host="corp-proxy.company.com",
    http_proxy_port=8080,
    proxy_type="http"
)

# Trong môi trường thử nghiệm (KHÔNG cho sản xuất!) có thể tắt kiểm tra:
ws_test = websocket.WebSocket(sslopt={"cert_reqs": ssl.CERT_NONE})
ws_test.connect("wss://test.example.com", http_proxy_host="proxy", http_proxy_port=8080)

⚠️ Quan trọng

Việc tắt kiểm tra chứng chỉ TLS (CERT_NONE) chỉ được phép trong môi trường thử nghiệm. Trong sản xuất, điều này tạo ra lỗ hổng cho các cuộc tấn công kiểu MITM (man-in-the-middle).

SNI (Server Name Indication) qua proxy

Khi sử dụng SOCKS5, khách hàng có thể tự giải quyết DNS hoặc ủy quyền cho proxy. Chế độ socks5h (SOCKS5 với giải quyết tên máy chủ) có nghĩa là yêu cầu DNS được thực hiện ở phía máy chủ proxy. Điều này rất quan trọng cho WSS, vì tiêu đề SNI trong TLS-handshake phải khớp với tên máy chủ: 

# socks5  — DNS được giải quyết cục bộ (bởi khách hàng)
# socks5h — DNS được giải quyết bởi máy chủ proxy (được khuyến nghị cho tính ẩn danh)

from python_socks.async_.asyncio import Proxy

# DNS qua proxy (được khuyến nghị):
proxy = Proxy.from_url("socks5h://user:[email protected]:1080")

# DNS cục bộ:
proxy = Proxy.from_url("socks5://user:[email protected]:1080")

Các lỗi thường gặp và cách khắc phục

Chúng tôi đã tổng hợp những vấn đề thường gặp nhất khi proxy hóa WebSocket cùng với các giải pháp:

Lỗi 1: 407 Proxy Authentication Required

Proxy yêu cầu xác thực, nhưng bạn chưa truyền thông tin đăng nhập hoặc đã truyền không chính xác. 

# ❌ Không đúng — không có xác thực
ws.connect("wss://example.com", http_proxy_host="proxy.example.com", http_proxy_port=8080)

# ✅ Đúng — truyền tên đăng nhập và mật khẩu
ws.connect(
    "wss://example.com",
    http_proxy_host="proxy.example.com",
    http_proxy_port=8080,
    http_proxy_auth=("username", "password")
)

Lỗi 2: Connection reset by peer / 502 Bad Gateway

Proxy không hỗ trợ WebSocket hoặc phương thức CONNECT. Giải pháp: chuyển sang SOCKS5 hoặc kiểm tra xem nhà cung cấp của bạn có hỗ trợ lưu lượng WebSocket hay không.

Lỗi 3: Kết nối bị ngắt sau 30-60 giây

Nhiều máy chủ proxy đóng các kết nối TCP "không hoạt động" theo thời gian chờ. Kết nối WebSocket có thể trông như không hoạt động nếu không có trao đổi dữ liệu. Giải pháp — bật ping/pong: 

# Python — bật ping keepalive mỗi 20 giây
import websocket
import threading

def run():
    ws = websocket.WebSocketApp(
        "wss://echo.websocket.org",
        on_message=lambda ws, msg: print(msg),
        on_error=lambda ws, err: print(f"Lỗi: {err}"),
        on_close=lambda ws, c, m: print("Đã đóng")
    )
    ws.run_forever(
        ping_interval=20,   # gửi ping mỗi 20 giây
        ping_timeout=10,    # chờ pong không quá 10 giây
        http_proxy_host="proxy.example.com",
        http_proxy_port=8080,
        proxy_type="socks5"
    )

thread = threading.Thread(target=run)
thread.start()

Lỗi 4: SSL: CERTIFICATE_VERIFY_FAILED

Thường xảy ra khi sử dụng proxy doanh nghiệp với kiểm tra SSL. Giải pháp: thêm chứng chỉ CA của proxy vào danh sách tin cậy (xem phần trên) hoặc sử dụng SOCKS5 thay vì proxy HTTP — SOCKS5 không thực hiện kiểm tra SSL.

Lỗi 5: Handshake status 403 Forbidden

Máy chủ đích chặn kết nối. Nguyên nhân: IP của proxy bị đưa vào danh sách đen, thiếu tiêu đề cần thiết (Origin, User-Agent), hoặc máy chủ chặn lưu lượng từ các trung tâm dữ liệu. Giải pháp: sử dụng proxy cư trú với IP thực của người dùng gia đình — chúng khó bị chặn hơn nhiều.

Lỗi 6: [Errno 111] Connection refused

Máy chủ proxy không khả dụng: địa chỉ/ cổng không chính xác, hoặc proxy không chạy. Kiểm tra thông tin kết nối và tính khả dụng của proxy qua một yêu cầu HTTP đơn giản trước khi thử nghiệm WebSocket.

Loại proxy nào nên chọn cho các tác vụ WebSocket

Việc chọn loại proxy phụ thuộc vào nhiệm vụ cụ thể. Dưới đây là hướng dẫn thực tế:

Nhiệm vụ Loại được khuyến nghị Tại sao
Phân tích qua WS (sàn giao dịch, dữ liệu tài chính) Proxy trung tâm dữ liệu Tốc độ cao, độ trễ thấp, kết nối ổn định
Vượt qua các chặn dịch vụ WebSocket Proxy cư trú IP thực, rủi ro chặn tối thiểu
Ứng dụng di động với WS (làm việc với API di động) Proxy di động IP của các nhà mạng di động — độ tin cậy cao từ các dịch vụ
Kiểm tra tải máy chủ WS Proxy trung tâm dữ liệu Rẻ, nhanh, nhiều kết nối đồng thời
Kiểm tra địa lý WS Proxy cư trú Nhiều lựa chọn quốc gia và thành phố

Các tham số quan trọng của proxy cho WebSocket

Khi chọn nhà cung cấp proxy cho các tác vụ WebSocket, hãy chú ý đến các tham số sau:

  • Hỗ trợ SOCKS5: đảm bảo rằng nhà cung cấp cung cấp SOCKS5, không chỉ HTTP
  • Thời gian phiên (session duration): đối với WebSocket, các phiên "dính" là quan trọng — một IP trong thời gian dài. Các proxy xoay vòng sẽ ngắt kết nối
  • Thời gian chờ kết nối: proxy phải hỗ trợ các kết nối TCP lâu dài (từ vài phút đến vài giờ)
  • Băng thông: đối với WebSocket phát trực tuyến (video, dữ liệu sàn giao dịch), băng thông cao mà không có giới hạn là quan trọng
  • Độ trễ (latency): đối với các ứng dụng tài chính và bot giao dịch, độ trễ tối thiểu là rất quan trọng — hãy chọn proxy với các máy chủ gần hơn đến dịch vụ mục tiêu

💡 Kiểm tra hỗ trợ WebSocket của nhà cung cấp proxy

Trước khi mua proxy cho các tác vụ WebSocket, hãy thử nghiệm chúng qua máy chủ echo miễn phí: wss://echo.websocket.org hoặc wss://ws.postman-echo.com/raw. Nếu kết nối được thiết lập và tin nhắn được trả về — proxy hoạt động với WebSocket một cách chính xác.

Cấu hình phiên dính cho WebSocket

Hầu hết các nhà cung cấp proxy cư trú sử dụng quay vòng IP theo mặc định. Đối với WebSocket, điều này là không thể chấp nhận — mỗi lần thay đổi IP có nghĩa là ngắt kết nối. Hãy đảm bảo rằng bạn đang sử dụng chế độ phiên dính (IP cố định). Thông thường, điều này được thực hiện thông qua định dạng URL proxy đặc biệt: 

# Ví dụ về định dạng phiên dính (tùy thuộc vào nhà cung cấp):
# Quay vòng (KHÔNG phù hợp cho WebSocket):
socks5://user:[email protected]:1080

# Phiên dính (phù hợp cho WebSocket):
socks5://user-session-abc123:[email protected]:1080

# Hoặc qua tham số quốc gia và phiên:
socks5://user-country-us-session-12345:[email protected]:1080

Kết luận

WebSocket không chỉ đơn giản là "HTTP với kết nối lâu dài". Đây là một giao thức riêng biệt, yêu cầu cách tiếp cận đặc biệt khi proxy hóa. Những kết luận chính từ bài viết này:

  • SOCKS5 — lựa chọn tối ưu cho WebSocket: hoạt động ở cấp độ giao thông, không phân tích giao thức, hỗ trợ bất kỳ cổng nào
  • Proxy HTTP qua CONNECT cũng hoạt động, nhưng có giới hạn về cổng và có thể gặp vấn đề với kiểm tra SSL
  • Phiên dính là bắt buộc: các proxy quay vòng sẽ ngắt kết nối WebSocket mỗi khi thay đổi IP
  • Ping/pong keepalive là cần thiết để ngăn ngừa ngắt kết nối do thời gian chờ của proxy
  • WSS qua proxy là an toàn: mã hóa TLS được thiết lập trực tiếp giữa khách hàng và máy chủ, proxy không thấy nội dung

Nếu bạn đang phát triển một ứng dụng hoạt động với WebSocket qua proxy — hãy bắt đầu với SOCKS5 và các phiên dính. Điều này sẽ tiết kiệm cho bạn hàng giờ gỡ lỗi. Đối với các tác vụ mà tốc độ cao và độ ổn định của kết nối là quan trọng (bot giao dịch, phát trực tuyến dữ liệu), proxy trung tâm dữ liệu với độ trễ thấp là lựa chọn tuyệt vời. Nếu dịch vụ mục tiêu thường xuyên chặn IP trung tâm dữ liệu — hãy xem xét proxy cư trú: chúng có IP thực của người dùng gia đình và ít bị chặn hơn nhiều ngay cả khi có các phiên WebSocket kéo dài.

```