وب‌سوکت از طریق پروکسی: تنظیم اتصالات WS/WSS

```html

WebSocket یک درخواست HTTP معمولی نیست. پس از «دست دادن» اولیه (handshake) اتصال باز می‌ماند و داده‌ها به صورت پیوسته در هر دو جهت جریان دارند. به همین دلیل است که پروکسی‌های HTTP استاندارد اغلب اتصالات WS را قطع می‌کنند یا اصلاً نمی‌توانند آنها را پردازش کنند. در این مقاله بررسی می‌کنیم که چگونه ترافیک WebSocket را به درستی پروکسی کنیم: کدام پروکسی‌ها مناسب هستند، چگونه آنها را تنظیم کنیم و کدام خطاها بیشتر اتفاق می‌افتند.

WebSocket چگونه کار می‌کند و چرا برای پروکسی پیچیده است

برای درک مشکل، باید در مکانیک آن بررسی کنیم. اتصال WebSocket به عنوان یک درخواست HTTP معمولی آغاز می‌شود - کلاینت هدر Upgrade: websocket و Connection: Upgrade را ارسال می‌کند. سرور با کد 101 Switching Protocols پاسخ می‌دهد - و از این لحظه اتصال دیگر HTTP نیست. این تبدیل به یک کانال دوطرفه دائمی می‌شود که داده‌ها در فریم‌ها جریان دارند.

پروکسی HTTP/1.1 استاندارد که فقط می‌تواند درخواست‌ها و پاسخ‌ها را ارسال کند، با مشکلی مواجه می‌شود: نمی‌داند بعد از پاسخ 101 چه کاری باید انجام دهد. بسیاری از سرورهای پروکسی در این لحظه فقط اتصال را می‌بندند یا خطای 502 Bad Gateway را برمی‌گردانند. دیگران اتصال را نگه می‌دارند، اما نمی‌توانند فریم‌های WebSocket را به درستی منتقل کنند که منجر به قطع یا تحریف داده‌ها می‌شود.

اینجا تفاوت‌های کلیدی WebSocket با HTTP معمولی از نظر پروکسی‌کردن است:

پارامتر	HTTP	WebSocket
نوع اتصال	درخواست → پاسخ → بستن	دائمی، دوطرفه
مدت زمان زندگی	ثانیه (یک درخواست)	دقیقه، ساعت، روز
مبدا داده‌ها	فقط کلاینت	کلاینت و سرور
پروتکل پس از handshake	HTTP	اختصاصی (RFC 6455)
پورت‌ها	80، 443	80 (WS)، 443 (WSS)

به همین دلیل که پروتکل پس از handshake تغییر می‌کند، بیشتر راه‌حل‌های پروکسی ساده نمی‌توانند با WebSocket کنار بیایند. باید یا از پروکسی استفاده کنید که به وضوح از تونل‌کردن پشتیبانی می‌کند، یا از SOCKS5 استفاده کنید - پروتکلی که در سطح پایین‌تری کار می‌کند و محتوای ترافیک را تجزیه نمی‌کند.

کدام نوع پروکسی از WebSocket پشتیبانی می‌کند

همه پروکسی‌ها به یک اندازه برای WebSocket مفید نیستند. بیایید هر نوع را بررسی کنیم:

نوع پروکسی	پشتیبانی از WS	مکانیزم	پیچیدگی
پروکسی HTTP	⚠️ جزئی	از طریق تونل CONNECT	متوسط
پروکسی HTTPS	✅ بله	CONNECT + TLS	متوسط
SOCKS4	⚠️ محدود	تونل TCP بدون auth	پایین
SOCKS5	✅ کامل	TCP/UDP شفاف	پایین
پروکسی شفاف	❌ خیر	فقط HTTP	—

نتیجه‌گیری: برای وظایف WebSocket، بهترین انتخاب SOCKS5 است. این پروتکل در سطح حمل و نقل کار می‌کند و فقط اتصال TCP را تونل می‌کند، بدون اینکه به محتوای ترافیک توجه کند. برایش مهم نیست که آیا درون آن HTTP، WebSocket، SSH یا چیز دیگری است. پروکسی‌های HTTP نیز می‌توانند با WS کار کنند، اما فقط از طریق روش CONNECT - و در اینجا نکات خاصی وجود دارد که در زیر بررسی خواهیم کرد.

روش CONNECT: چگونه پروکسی HTTP WebSocket را تونل می‌کند

روش HTTP CONNECT یک مکانیزم خاص است که به پروکسی HTTP اجازه می‌دهد تا یک تونل «کور» به سرور هدف ایجاد کند. پروکسی ترافیک داخل تونل را تجزیه نمی‌کند و فقط بایت‌ها را منتقل می‌کند. اینگونه است که HTTPS از طریق پروکسی HTTP کار می‌کند - و اینگونه می‌توان WebSocket را پروکسی کرد.

فرآیند به صورت زیر است:

کلاینت درخواست پروکسی را ارسال می‌کند: CONNECT example.com:443 HTTP/1.1
پروکسی یک اتصال TCP با example.com:443 برقرار می‌کند
پروکسی به کلاینت پاسخ می‌دهد: 200 Connection Established
از این لحظه به بعد پروکسی فقط بایت‌ها را به جلو و عقب منتقل می‌کند - بدون تجزیه آنها
کلاینت TLS-handshake را به طور مستقیم با سرور از طریق تونل انجام می‌دهد
سپس - WebSocket-handshake روی TLS

محدودیت کلیدی: روش CONNECT معمولاً فقط برای پورت 443 مجاز است. اگر سرور WebSocket شما در پورت غیر استانداردی (مانند 8080 یا 9000) کار می‌کند، پروکسی ممکن است اتصال را رد کند. در این صورت SOCKS5 ترجیح داده می‌شود - زیرا هیچ محدودیتی در پورت‌ها ندارد.

همچنین مهم است که در نظر داشته باشید که برخی از پروکسی‌های HTTP شرکتی (مانند Squid در پیکربندی استاندارد) به وضوح روش CONNECT را برای پورت‌های خاصی مسدود می‌کنند یا نیاز به احراز هویت دارند. اگر با ارائه‌دهندگان پروکسی تجاری کار می‌کنید، بیشتر آنها از CONNECT بدون محدودیت پشتیبانی می‌کنند.

# نمونه درخواست CONNECT از طریق curl (برای بررسی)
curl -v -x http://proxy_host:proxy_port \
  --proxytunnel \
  https://echo.websocket.org

# اگر پروکسی از CONNECT پشتیبانی کند - خواهید دید:
# * CONNECT tunnel established, response 200

SOCKS5 و WebSocket: چرا این بهترین گزینه است

SOCKS5 یک پروتکل پروکسی‌کردن در سطح اتصالات TCP/UDP است. بر خلاف پروکسی HTTP، SOCKS5 هیچ چیز درباره پروتکل کاربردی که درون آن است نمی‌داند. این فقط یک تونل بین کلاینت و سرور هدف ایجاد می‌کند و بس. این ویژگی آن را برای WebSocket ایده‌آل می‌کند به چند دلیل:

هیچ محدودیتی در پروتکل: SOCKS5 هر ترافیک TCP را تونل می‌کند، از جمله WS، WSS، SSH، FTP و غیره.
هیچ محدودیتی در پورت‌ها: با هر پورتی کار می‌کند، نه فقط 443 یا 80
هیچ قطع ارتباطی در هنگام تغییر پروتکل: پروکسی «نمی‌بیند» انتقال از HTTP به WebSocket
پشتیبانی از احراز هویت: SOCKS5 از نام کاربری/گذرواژه پشتیبانی می‌کند که برای پروکسی‌های تجاری مناسب است
پشتیبانی از UDP: اگر برنامه شما از WebRTC یا UDP در کنار WS استفاده می‌کند - SOCKS5 کار خواهد کرد

تقریباً تمام کتابخانه‌های مدرن برای کار با WebSocket از SOCKS5 یا به طور مستقیم یا از طریق بسته‌های اضافی پشتیبانی می‌کنند. در زیر نمونه‌های خاصی برای Python و Node.js بررسی خواهیم کرد.

💡 چه زمانی SOCKS5 را انتخاب کنیم و چه زمانی HTTP CONNECT؟

از SOCKS5 استفاده کنید، اگر: پورت غیر استاندارد است، نیاز به پشتیبانی از UDP دارید، می‌خواهید حداقل تنظیمات را داشته باشید.
از HTTP CONNECT استفاده کنید، اگر: ارائه‌دهنده پروکسی از SOCKS5 پشتیبانی نمی‌کند، یا از طریق پروکسی شرکتی کار می‌کنید.

نمونه‌های کد: WebSocket از طریق پروکسی در Python

چندین سناریو برای Python را بررسی می‌کنیم. محبوب‌ترین کتابخانه‌ها برای WebSocket در Python عبارتند از websockets و websocket-client.

گزینه 1: websocket-client از طریق پروکسی HTTP

import websocket

# تنظیمات پروکسی 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"  # یا "socks5"
)

ws.send("سلام، WebSocket!")
result = ws.recv()
print(f"دریافت شده: {result}")

ws.close()

گزینه 2: websocket-client از طریق SOCKS5

import websocket

# برای SOCKS5 به بسته نیاز دارید: 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("پیام آزمایشی")
print(ws.recv())
ws.close()

گزینه 3: کتابخانه websockets (asyncio) از طریق SOCKS5

کتابخانه websockets (asyncio) از پشتیبانی داخلی پروکسی برخوردار نیست، بنابراین از python-socks برای ایجاد تونل استفاده می‌کنیم:

# 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")
    
    # ایجاد اتصال TCP از طریق پروکسی
    sock = await proxy.connect(
        dest_host="echo.websocket.org",
        dest_port=443
    )
    
    # انتقال سوکت به websockets
    async with websockets.connect(
        "wss://echo.websocket.org",
        sock=sock
    ) as ws:
        await ws.send("سلام از طریق SOCKS5!")
        response = await ws.recv()
        print(f"پاسخ: {response}")

asyncio.run(connect_via_socks5())

گزینه 4: پچ جهانی از طریق PySocks

اگر می‌خواهید تمام ترافیک برنامه Python را از طریق SOCKS5 بدون تغییر هر فراخوانی هدایت کنید - از socks.setdefaultproxy() استفاده کنید:

# pip install PySocks
import socks
import socket
import websocket

# پچ کردن سوکت به صورت جهانی
socks.set_default_proxy(
    socks.SOCKS5,
    "proxy.example.com",
    1080,
    username="user",
    password="pass"
)
socket.socket = socks.socksocket

# حالا همه اتصالات از طریق SOCKS5 انجام می‌شود
ws = websocket.WebSocket()
ws.connect("wss://echo.websocket.org")
ws.send("پروکسی جهانی SOCKS5!")
print(ws.recv())
ws.close()

نمونه‌های کد: WebSocket از طریق پروکسی در Node.js

در اکوسیستم Node.js، محبوب‌ترین کتابخانه برای WebSocket ws است. برای پروکسی‌کردن از طریق HTTP/SOCKS5 از بسته https-proxy-agent یا socks-proxy-agent استفاده می‌شود.

گزینه 1: WSS از طریق پروکسی 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('اتصال از طریق پروکسی HTTP برقرار شد');
  ws.send('سلام از Node.js!');
});

ws.on('message', (data) => {
  console.log(`دریافت شده: ${data}`);
  ws.close();
});

ws.on('error', (err) => {
  console.error('خطا:', err.message);
});

گزینه 2: WSS از طریق 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('اتصال از طریق SOCKS5 برقرار شد');
  ws.send(JSON.stringify({ type: 'ping', data: 'test' }));
});

ws.on('message', (data) => {
  console.log('پاسخ:', data.toString());
});

ws.on('close', (code, reason) => {
  console.log(`بسته شد: ${code} - ${reason}`);
});

گزینه 3: WS (بدون TLS) از طریق پروکسی HTTP به صورت دستی

برای WS غیر رمزگذاری شده (پورت 80) از طریق پروکسی HTTP، باید به صورت دستی درخواست CONNECT را ارسال کنید، زیرا عوامل استاندارد معمولاً فقط با 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(`پروکسی درخواست 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('تونل CONNECT دستی!');
  });

  ws.on('message', (data) => {
    console.log('دریافت شده:', data.toString());
    ws.close();
  });
}

main().catch(console.error);

WSS (WebSocket Secure): ویژگی‌های پروکسی‌کردن با TLS

WSS یک WebSocket بر روی TLS است (مشابه HTTPS برای HTTP). هنگام پروکسی‌کردن WSS از طریق SOCKS5 یا HTTP CONNECT، یک نکته مهم وجود دارد: رمزگذاری TLS بین کلاینت و سرور نهایی برقرار می‌شود، نه بین کلاینت و پروکسی. این بدان معناست که:

سرور پروکسی محتوای ترافیک WSS را نمی‌بیند - فقط آدرس IP و پورت مقصد را می‌بیند
گواهی سرور به طور مستقیم توسط کلاینت بررسی می‌شود
پروکسی نمی‌تواند داده‌ها را «جایگزین» یا «دستگیر» کند مگر اینکه گواهی CA خود را نصب کند

این خبر خوبی از نظر امنیت است. اما در تنظیمات عملی نیز نکات خاصی وجود دارد:

بررسی گواهی از طریق پروکسی

گاهی اوقات هنگام استفاده از پروکسی‌های شرکتی (که بازرسی SSL انجام می‌دهند) ممکن است با خطای بررسی گواهی مواجه شوید. در این صورت پروکسی گواهی سرور را با گواهی خود جایگزین می‌کند. برای کار در چنین محیطی باید گواهی CA پروکسی را به لیست مورد اعتماد اضافه کنید:

# Python: گواهی CA پروکسی شرکتی را ارسال کنید
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"
)

# در محیط‌های آزمایشی (نه برای تولید!) می‌توانید بررسی را غیرفعال کنید:
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)

⚠️ مهم

غیرفعال کردن بررسی گواهی TLS (CERT_NONE) فقط در محیط آزمایشی مجاز است. در تولید، این یک آسیب‌پذیری برای حملات MITM (man-in-the-middle) ایجاد می‌کند.

SNI (Server Name Indication) از طریق پروکسی

هنگام استفاده از SOCKS5، کلاینت می‌تواند DNS را به صورت خودکار حل کند یا این کار را به پروکسی واگذار کند. حالت socks5h (SOCKS5 با حل نام میزبان) به این معنی است که درخواست DNS در سمت سرور پروکسی انجام می‌شود. این برای WSS مهم است، زیرا هدر SNI در TLS-handshake باید با نام میزبان مطابقت داشته باشد:

# socks5  — DNS به صورت محلی (توسط کلاینت) حل می‌شود
# socks5h — DNS توسط سرور پروکسی حل می‌شود (برای ناشناس بودن توصیه می‌شود)

from python_socks.async_.asyncio import Proxy

# DNS از طریق پروکسی (توصیه می‌شود):
proxy = Proxy.from_url("socks5h://user:[email protected]:1080")

# DNS به صورت محلی:
proxy = Proxy.from_url("socks5://user:[email protected]:1080")

خطاهای رایج و نحوه رفع آنها

ما رایج‌ترین مشکلات در پروکسی‌کردن WebSocket را با راه‌حل‌ها جمع‌آوری کرده‌ایم:

خطا 1: 407 نیاز به احراز هویت پروکسی

پروکسی نیاز به احراز هویت دارد، اما شما اطلاعات کاربری را ارسال نکرده‌اید یا به اشتباه ارسال کرده‌اید.

# ❌ نادرست — بدون احراز هویت
ws.connect("wss://example.com", http_proxy_host="proxy.example.com", http_proxy_port=8080)

# ✅ درست — ارسال نام کاربری و گذرواژه
ws.connect(
    "wss://example.com",
    http_proxy_host="proxy.example.com",
    http_proxy_port=8080,
    http_proxy_auth=("username", "password")
)

خطا 2: Connection reset by peer / 502 Bad Gateway

پروکسی از WebSocket یا روش CONNECT پشتیبانی نمی‌کند. راه‌حل: به SOCKS5 سوئیچ کنید یا بررسی کنید که آیا ارائه‌دهنده شما از ترافیک WebSocket پشتیبانی می‌کند.

خطا 3: اتصال در 30-60 ثانیه قطع می‌شود

بسیاری از سرورهای پروکسی اتصالات TCP «غیرفعال» را به دلیل تایم‌اوت می‌بندند. اتصال WebSocket ممکن است در صورت عدم تبادل داده‌ها غیرفعال به نظر برسد. راه‌حل - فعال‌سازی ping/pong:

# Python — فعال‌سازی ping هر 20 ثانیه
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"خطا: {err}"),
        on_close=lambda ws, c, m: print("بسته شد")
    )
    ws.run_forever(
        ping_interval=20,   # ارسال ping هر 20 ثانیه
        ping_timeout=10,    # انتظار برای pong حداکثر 10 ثانیه
        http_proxy_host="proxy.example.com",
        http_proxy_port=8080,
        proxy_type="socks5"
    )

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

خطا 4: SSL: CERTIFICATE_VERIFY_FAILED

این خطا بیشتر اوقات هنگام استفاده از پروکسی شرکتی با بازرسی SSL رخ می‌دهد. راه‌حل: گواهی CA پروکسی را به لیست مورد اعتماد اضافه کنید (به بخش بالا مراجعه کنید) یا از SOCKS5 به جای پروکسی HTTP استفاده کنید - SOCKS5 بازرسی SSL انجام نمی‌دهد.

خطا 5: وضعیت handshake 403 Forbidden

سرور هدف اتصال را مسدود می‌کند. دلایل: IP پروکسی در لیست سیاه قرار دارد، هدرهای مورد نیاز (Origin، User-Agent) وجود ندارد، یا سرور ترافیک را از مراکز داده مسدود می‌کند. راه‌حل: از پروکسی‌های مسکونی با IP‌های واقعی کاربران خانگی استفاده کنید - مسدود کردن آنها به مراتب دشوارتر است.

خطا 6: [Errno 111] Connection refused

سرور پروکسی در دسترس نیست: میزبان/پورت نادرست است، یا پروکسی راه‌اندازی نشده است. اطلاعات اتصال و در دسترس بودن پروکسی را از طریق یک درخواست HTTP ساده قبل از آزمایش WebSocket بررسی کنید.

کدام نوع پروکسی را برای وظایف WebSocket انتخاب کنیم

انتخاب نوع پروکسی بستگی به وظیفه خاص دارد. در اینجا یک راهنمای عملی ارائه می‌شود:

وظیفه	نوع پیشنهادی	چرا
پارسینگ از طریق WS (بورس، داده‌های مالی)	پروکسی‌های مراکز داده	سرعت بالا، تأخیر کم، اتصال پایدار
دور زدن مسدودیت‌های خدمات WebSocket	پروکسی‌های مسکونی	IP‌های واقعی، حداقل ریسک مسدودیت
برنامه‌های موبایل با WS (کار با API‌های موبایل)	پروکسی‌های موبایل	IP‌های اپراتورهای موبایل - اعتماد بالا از سوی خدمات
آزمون بار WS سرور	پروکسی‌های مراکز داده	ارزان، سریع، تعداد زیادی اتصال همزمان
آزمون جغرافیایی WS	پروکسی‌های مسکونی	تنوع بالا در کشورهای مختلف

پارامترهای مهم پروکسی برای WebSocket

هنگام انتخاب ارائه‌دهنده پروکسی برای وظایف WebSocket به پارامترهای زیر توجه کنید:

پشتیبانی از SOCKS5: اطمینان حاصل کنید که ارائه‌دهنده SOCKS5 را ارائه می‌دهد، نه فقط HTTP
مدت زمان جلسه (session duration): برای WebSocket جلسات «چسبنده» مهم هستند - یک IP برای مدت طولانی. پروکسی‌های چرخشی اتصال را قطع می‌کنند
تایم‌اوت اتصال: پروکسی باید از اتصالات TCP با عمر طولانی (از چند دقیقه تا ساعت‌ها) پشتیبانی کند
عرض باند: برای WebSocket استریم (ویدئو، داده‌های بورس) عرض باند بالای بدون محدودیت مهم است
تأخیر (latency): برای برنامه‌های مالی و ربات‌های تجاری تأخیر حداقلی حیاتی است - پروکسی با سرورهای نزدیک به سرویس هدف را انتخاب کنید

💡 بررسی پشتیبانی WebSocket توسط ارائه‌دهنده پروکسی

قبل از خرید پروکسی برای وظایف WebSocket، آنها را از طریق سرور اکو رایگان آزمایش کنید: wss://echo.websocket.org یا wss://ws.postman-echo.com/raw. اگر اتصال برقرار شود و پیام‌ها بازگردانده شوند - پروکسی به درستی با WebSocket کار می‌کند.

تنظیم جلسه چسبنده برای WebSocket

بیشتر ارائه‌دهندگان پروکسی‌های مسکونی به طور پیش‌فرض از چرخش IP استفاده می‌کنند. برای WebSocket این قابل قبول نیست - هر تغییر IP به معنای قطع اتصال است. اطمینان حاصل کنید که از حالت جلسه چسبنده (sticky session) استفاده می‌کنید. معمولاً این کار از طریق فرمت خاص URL پروکسی انجام می‌شود:

# نمونه فرمت جلسه چسبنده (بستگی به ارائه‌دهنده دارد):
# چرخشی (مناسب برای WebSocket نیست):
socks5://user:[email protected]:1080

# جلسه چسبنده (مناسب برای WebSocket):
socks5://user-session-abc123:[email protected]:1080

# یا از طریق پارامتر کشور و جلسه:
socks5://user-country-us-session-12345:[email protected]:1080

نتیجه‌گیری

WebSocket فقط «HTTP با اتصال طولانی» نیست. این یک پروتکل جداگانه است که نیاز به رویکرد خاصی در پروکسی‌کردن دارد. نکات اصلی این مقاله:

SOCKS5 - انتخاب بهینه برای WebSocket: در سطح حمل و نقل کار می‌کند، پروتکل را تجزیه نمی‌کند، از هر پورتی پشتیبانی می‌کند
پروکسی HTTP از طریق CONNECT نیز کار می‌کند، اما با محدودیت‌هایی در پورت‌ها و مشکلات احتمالی با بازرسی SSL
جلسات چسبنده الزامی هستند: پروکسی‌های چرخشی با هر تغییر IP اتصال WebSocket را قطع می‌کنند
Ping/pong keepalive برای جلوگیری از قطع اتصال به دلیل تایم‌اوت پروکسی ضروری است
WSS از طریق پروکسی ایمن است: رمزگذاری TLS به طور مستقیم بین کلاینت و سرور برقرار می‌شود، پروکسی محتوای آن را نمی‌بیند

اگر شما یک برنامه توسعه می‌دهید که با WebSocket از طریق پروکسی کار می‌کند - با SOCKS5 و جلسات چسبنده شروع کنید. این کار به شما در صرفه‌جویی در ساعت‌ها عیب‌یابی کمک می‌کند. برای وظایفی که سرعت و ثبات اتصال بالا مهم است (ربات‌های تجاری، استریم داده‌ها)، پروکسی‌های مراکز داده با تأخیر کم گزینه‌های عالی هستند. اگر سرویس هدف به طور فعال IP‌های مراکز داده را مسدود می‌کند - پروکسی‌های مسکونی را در نظر بگیرید: آنها IP‌های واقعی کاربران خانگی دارند و به مراتب کمتر تحت مسدودیت قرار می‌گیرند حتی در طول جلسات WebSocket طولانی.