Підтримка UDP через SOCKS5 (QUIC / HTTP/3)
Сучасні веб-сервіси активно переходять на HTTP/3, який працює поверх QUIC, а QUIC - поверх UDP.
Для браузерних платформ це означає необхідність повноцінної маршрутизації не лише TCP-трафіку, а й UDP-з'єднань через проксі.
Якщо UDP не проходить через проксі-тунель, виникають мережеві несоответствия, а в окремих випадках - ризик витоку реальної IP-адреси.
Чому підтримка UDP критично важлива
Браузер може:
- оголошувати підтримку HTTP/3
- використовувати сучасний TLS-стек
- коректно формувати fingerprint
Але якщо QUIC не маршрутизується через проксі, відбувається одне з наступного:
- HTTP/3 не встановлюється
- з'єднання примусово понижується до HTTP/2
- UDP-трафік виходить безпосередньо
Для сучасних антифрод-систем це є індикатором мережевої аномалії.
Архітектурний підхід
Повноцінна реалізація включає:
- підтримку механізму SOCKS5 UDP ASSOCIATE
- передачу QUIC-датаграм через проксі-IP
- коректне встановлення HTTP/3 без fallback
- узгоджену роботу з мережевим стеком Chromium
В результаті сервер бачить IP проксі для всього трафіку - як TCP, так і UDP.
Технічна схема маршрутизації (Packet Flow)
Нижче наведена спрощена схема проходження QUIC-трафіку через SOCKS5:
Деталізація процесу
- Браузер встановлює TCP-з'єднання з SOCKS5-проксі
- Виконується команда
UDP ASSOCIATE - Проксі виділяє UDP-порт для передачі датаграм
- QUIC-пакети передаються через цей UDP-канал
- Цільовий сервер отримує трафік з IP проксі
При такій архітектурі відсутній:
- прямий UDP-трафік обхідом проксі
- примусове пониження HTTP/3
- несоответствие мережевої поведінки
Що це дає на практиці
- Консистентність мережевого профілю
- Реалістична поведінка сучасного браузера
- Коректний HTTP/3 handshake
- Відсутність IP-витоків через UDP
- Підвищену стійкість до мережевих перевірок
Технологічна складність
SOCKS5 історично орієнтований на TCP-з'єднання. Підтримка UDP потребує:
- окремої обробки датаграмних пакетів
- коректної маршрутизації без конфліктів NAT
- синхронізації з QUIC-стеком
- інтеграції на рівні мережевої архітектури браузера
Це завдання системного рівня, що потребує глибокої роботи з мережевим стеком.
Висновок
Підтримка UDP через SOCKS5 - обов'язковий елемент сучасної браузерної платформи, що працює з HTTP/3.
Повноцінна маршрутизація QUIC-трафіку через проксі забезпечує мережеву цілісність, реалістичність та захист від IP-витоків.
Afina Browser реалізує це на рівні рушія.
Без обхідних рішень. Без обходу проксі. Без деградації протоколів.
QUIC-трафік коректно маршрутизується через проксі-стек із збереженням HTTP/3 та мережевої ізоляції.
Сучасні протоколи мають підтримуватися нативно.
Afina це забезпечує.
СкачатиFAQ — Часті запитання
Чому підтримка UDP у проксі раптом стала важливою?
Тому що веб переходить на HTTP/3, а HTTP/3 працює поверх QUIC — протоколу на базі UDP. Якщо ваше проксі маршрутизує лише TCP, то QUIC-трафік або йде напряму (минаючи проксі), або взагалі не встановлюється, і браузер відкочується на HTTP/2. Обидва варіанти створюють мережеву аномалію, яку легко детектити.
Що саме «протікає», якщо UDP не йде через проксі?
Залежно від конфігурації браузера — одне з двох:
- Прямий витік IP — QUIC-датаграми йдуть з вашого реального IP до цільового сервера, а TCP — через проксі. Сервер бачить дві різні IP-адреси в межах однієї сесії.
- Невідповідність протокольного відбитку — браузер заявляє підтримку HTTP/3, але з'єднання мовчки відкочується. Анти-фрод системи фіксують цю невідповідність.
HTTP/3 справді вже настільки поширений?
Так. Cloudflare, Google, Meta, YouTube, Cloudfront, Akamai та більшість великих CDN віддають HTTP/3 за замовчуванням сумісним клієнтам. Якщо ваш браузер заявляє підтримку HTTP/3, але ніколи її реально не використовує — це вже само по собі відбиток.
Чи можу я просто вимкнути HTTP/3 у браузері, щоб уникнути проблеми?
Технічно — так, але це робить ситуацію гіршою. Сучасна збірка Chrome з примусово вимкненим HTTP/3 статистично рідкісна і виділяється. Анти-детект платформи прагнуть до реалізму — вимкнення QUIC є його протилежністю.
Що таке SOCKS5 UDP ASSOCIATE?
Це частина протоколу SOCKS5 (RFC 1928), призначена для ретрансляції UDP. Клієнт надсилає команду UDP ASSOCIATE через TCP, проксі виділяє UDP-порт, і з цього моменту датаграми тунелюються через проксі. Більшість реалізацій SOCKS5 пропускають цю частину, бо тільки-TCP реалізувати простіше.
Чи всі SOCKS5-проксі підтримують UDP ASSOCIATE?
Ні, і це підводний камінь. Багато комерційних провайдерів проксі рекламують «SOCKS5», але реалізують лише TCP-частину. Перш ніж покладатися на провайдера для маршрутизації HTTP/3, потрібно реально протестувати UDP ASSOCIATE — реклама не означає підтримку.
Чи підтримує HTTP-проксі UDP?
Ні. HTTP та HTTPS проксі за дизайном працюють лише з TCP. Для маршрутизації QUIC потрібен SOCKS5 з повноцінним UDP ASSOCIATE або тунель вищого рівня (WireGuard, OpenVPN у UDP-режимі тощо).
Чим Afina Browser обробляє це інакше, ніж звичайний Chromium?
У штатному Chromium немає вбудованої концепції маршрутизації QUIC через SOCKS5 — він або використовує системний проксі (тільки TCP), або надсилає QUIC напряму. Afina інтегрує UDP-ретрансляцію на рівні мережевого стеку, тому QUIC-датаграми загортаються в SOCKS5 UDP ASSOCIATE пакети ще до того, як покинути машину.
Чи сповільнить це з'єднання?
Є невелика накладна вартість через інкапсуляцію SOCKS5 UDP (близько 10 байтів на пакет), але сам QUIC швидший за TCP+TLS, тому чистий ефект зазвичай нейтральний або позитивний порівняно з HTTP/2 через проксі.
Як щодо IPv6 і QUIC?
QUIC працює як через IPv4, так і через IPv6. Якщо ваше проксі надає лише IPv4, а цільовий сервер віддає перевагу IPv6, браузер може спробувати пряме IPv6 QUIC-з'єднання. Коректна реалізація примусово направляє весь QUIC-трафік через проксі незалежно від сімейства адрес.
Як перевірити, що QUIC справді маршрутизується через проксі?
Три швидкі перевірки:
- Відкрийте
chrome://net-export/, захопіть сесію та перевірте IP-адреси QUIC-з'єднань - Зайдіть на
https://cloudflare-quic.com/— він показує, чи встановлено HTTP/3 - Перевірте перспективу цільового сервера через сайт типу
https://browserleaks.com/ip, паралельно завантажуючи сайт з HTTP/3
Що відбувається з WebRTC, якщо UDP іде через проксі?
WebRTC також використовує UDP, але це окрема проблема зі своїми векторами витоку через STUN/TURN. Маршрутизація QUIC через SOCKS5 не виправляє автоматично витоки WebRTC — вони потребують окремої обробки на рівні браузера (що Afina також забезпечує).
Це проблема лише для анти-детект браузерів, чи для звичайних користувачів теж?
Для звичайних користувачів, що дбають про приватність, це теж має значення. VPN, який не маршрутизує UDP, або split-tunnel конфігурації можуть злити реальний IP через QUIC. Користувачі анти-детект просто стикаються з вищими наслідками, бо анти-фрод системи активно це перевіряють.
Як щодо HTTP/3 connection migration — чи працює це через проксі?
QUIC підтримує міграцію з'єднання (зміна мережі без розриву). При маршрутизації через SOCKS5 UDP ASSOCIATE міграція продовжує працювати, доки проксі підтримує UDP-асоціацію. Connection ID залишається стабільним, змінюється лише базовий транспорт.
Чи можуть системи детекції відрізнити нативний HTTP/3 від HTTP/3 через SOCKS5?
При коректній реалізації — ні. Цільовий сервер бачить лише QUIC-пакети, що приходять з IP проксі, ідентичні за формою пакетам, надісланим нативно. Детекція спирається на невідповідності (розбіжність IP, відсутність HTTP/3 при його заявленні, аномалії затримки), а не на структуру пакетів.
Де можна прочитати специфікації протоколів?
- SOCKS5: RFC 1928
- SOCKS5 UDP ASSOCIATE: Розділ 7 RFC 1928
- QUIC: RFC 9000
- HTTP/3: RFC 9114
