Українська
VLESS + Reality Посібник: Безпечне налаштування проксі
Ключові терміни
Перед тим як розпочати налаштування, ось основні терміни, які найімовірніше потребуватимуть уточнення в цьому посібнику.
| Термін | Визначення |
|---|---|
| 🔐 VLESS | Легкий протокол проксі з екосистеми V2Ray/Xray, який автентифікує користувачів за допомогою UUID і зазвичай поєднується з сучасними транспортами приховування, такими як Reality. |
| 🔀 Proxy vs VPN | Проксі зазвичай перенаправляє трафік додатків через сервер, тоді як традиційний VPN зазвичай створює повний віртуальний мережевий тунель для пристрою або системи. |
| 🎭 Reality | Механізм приховування транспорту для Xray, який робить трафік набагато більш схожим на звичайний HTTPS, використовуючи TLS-відбитки, подібні до браузера, та спеціальну валідацію на основі ключів. |
| 🔍 DPI (Deep Packet Inspection) | Техніка фільтрування мережі, яка аналізує шаблони пакетів, рукостискання та відбитки протоколів для ідентифікації та блокування трафіку, такого як VPN та проксі. |
| 🖥️ VPS | Віртуальний приватний сервер, який ви орендуєте та контролюєте віддалено, який служить хост-машиною для вашого налаштування VLESS + Reality. |
| ⚙️ 3x-ui | Веб-панель управління для Xray, яка дозволяє вам створювати inbound, користувачів та параметри Reality без ручного редагування JSON. |
| 🚀 Xray | Основний механізм проксі, що працює під 3x-ui, який фактично обробляє VLESS, Reality, маршрутизацію та з’єднання клієнтів. |
| 🆔 UUID | Унікальний ідентифікатор, призначений кожному клієнту та використовуваний VLESS як основне значення автентифікації. |
| 🌐 SNI | Server Name Indication, поле TLS, яке повідомляє серверу, яке ім’я хоста запитується, і повинно правильно відповідати конфігурації цілі Reality. |
| 🧬 x25519 Key Pair | Пара публічного/приватного ключа, яка використовується Reality, щоб дозволені клієнти могли завершити з’єднання, тоді як небажані проби обробляються інакше. |
| 🔑 Public key vs private key | Публічний ключ поділяється з клієнтом, щоб він міг підключитися, тоді як приватний ключ залишається тільки на сервері і ніколи не повинен бути розкритий. |
| 🧭 uTLS Fingerprint | TLS-відбиток клієнта, що імітує браузер, такий як chrome, використовується для того, щоб з’єднання виглядало як звичайний трафік браузера. |
| 📡 Inbound | Конфігурація слухача на стороні сервера в Xray/3x-ui, яка визначає, як клієнти підключаються, включаючи протокол, порт, транспорт та параметри безпеки. |
| ⚡ BBR | Алгоритм контролю перегруження TCP від Google, який може покращити пропускну здатність та чутливість на деяких мережевих шляхах VPS. |
| ✅ ACME validation | Крок публічної верифікації, використовуваний сервісами сертифікатів, такими як Let’s Encrypt, для підтвердження того, що ваш сервер або домен доступний і дозволений для запиту сертифіката. |
Налаштування VLESS VPN з Reality Stealth у 2026
Розчарування знайоме: ви налаштовуєте VPN-сервер, все працює ідеально, а потім одного ранку виявляєте, що його заблоковано. З’єднання, яке вчора працювало, сьогодні не працює. З вашого боку змін немає, але раптом нічого не працює. Це не гіпотетичний сценарій—це реальність використання традиційних VPN-протоколів у 2026, де технологія глибокого аналізу пакетів еволюціонувала настільки, що може виявляти та блокувати навіть належним чином зашифрований трафік.
Рішення—це не інший алгоритм шифрування чи швидший протокол, а принципово інший підхід до того, як ваш трафік виглядає в мережі. VLESS у поєднанні з протоколом Reality stealth—один із найефективніших самостійно розгорнутих підходів, доступних у 2026, для того щоб зробити трафік проксі набагато більш схожим на звичайний HTTPS-трафік. Цей посібник проведе вас через розгортання власного сервера VLESS + Reality за допомогою панелі керування 3x-ui, від розуміння того, чому цей підхід працює, до налаштування робочого з’єднання на вашому пристрої.
Проблема: Чому стандартні VPN блокуються
Часи, коли простий OpenVPN або WireGuard сервер працював надійно місяцями—або навіть роками—закінчилися. Технологія Deep Packet Inspection (DPI) розвинулася драматично, і тепер це не просто про виявлення незашифрованого трафіку. Сучасні DPI системи аналізують численні характеристики вашого мережевого трафіку, щоб ідентифікувати VPN з’єднання з надзвичайною точністю.
Розглянемо, що відбувається, коли ви підключаєтеся за допомогою стандартного OpenVPN або WireGuard. Трафік зашифрований, але він все ще має впізнавану форму. OpenVPN часто розкриває TLS handshake та паттерн трафіку, який не виглядає як звичайна сесія браузера. WireGuard взагалі не використовує TLS, але його UDP-based handshake та поведінка пакетів все ще достатньо характерні, щоб виділитися на фільтрованих мережах. Це як мати паспорт з неправильним кодом країни—документ дійсний, але деталі не відповідають жодному легітимному мандрівнику.
У 2026 році це блокування відбувається швидше, ніж коли-небудь раніше. Якщо раніше новий VPN міг працювати місяцями перед виявленням, то тепер нові сервери можуть бути ідентифіковані протягом днів або навіть годин після запуску. Блокування також більш поширене, відбувається на рівні ISP, на рівні корпоративної мережі та в деяких юрисдикціях на рівні національного брандмауера. Вам потрібне рішення, яке не просто шифрує ваш трафік—воно змушує ваш трафік виглядати як щось зовсім інше.
Що таке VLESS? Пояснення протоколу
VLESS розшифровується як “VMess Less”—назва, яка безпосередньо відображає його філософію проектування. Він був створений як легший, простіший наступник протоколу VMess, який був оригінальним стандартним транспортним протоколом у проекті V2Ray. Якщо VMess об’єднував шифрування, аутентифікацію та транспорт в одну тісно пов’язану систему, VLESS позбавляється непотрібних шарів і залишає чистий, без стану транспортний протокол.
Ось критична відмінність: VLESS функціонує як проксі, а не як повний VPN-тунель. Протокол перенаправляє ваш трафік через сервер, а не створює повний віртуальний мережевий інтерфейс. Для більшості користувачів ця відмінність є академічною—функціональний результат є саме тим, чого ви очікуєте від VPN: ваш трафік виглядає так, ніби він походить з IP-адреси сервера. Але саме ця архітектура проксі є причиною того, чому VLESS так добре працює з Reality, оскільки легший накладний витрати протоколу дозволяють механізму приховування працювати без перешкод.
Дизайн проксі також означає менше накладних витрат порівняно з традиційними VPN-протоколами. Немає інтерфейсу тунелю на рівні ядра для управління, немає додаткових шарів шифрування поза необхідним, і протокол був розроблений з нуля для роботи з сучасними механізмами приховування на основі TLS. Ця простота—це особливість, а не обмеження—це означає, що менше речей може піти не так і менше відбитків, які можуть бути виявлені.
Розуміння реальності: технологія Stealth
Reality — це те, що перетворює VLESS з простого прокси-протоколу на щось набагато складніше для розрізнення від звичайного зашифрованого веб-трафіку. Механізм елегантний у своїй простоті: замість того, щоб приховувати те, що ви робите, Reality змушує ваш трафік виглядати як щось зовсім інше.
Reality досягає цього за допомогою техніки, яка працює на рівні TLS handshake. Коли клієнт підключається до вашого сервера, він надсилає TLS ClientHello, який імітує справжній браузер — використовуючи бібліотеку uTLS для відтворення відбитка Chrome, Firefox або іншого популярного браузера. Сервер потім перевіряє з’єднання, використовуючи матеріал ключів Reality та параметри клієнта, побудовані навколо пари ключів x25519. Якщо клієнт представляє очікувані значення Reality, з’єднання продовжується як VLESS прокси. Якщо ні — що відбувається, коли система DPI або активний зонд потрапляють на ваш сервер — трафік перенаправляється на легітимний цільовий веб-сайт, такий як www.microsoft.com або www.apple.com. Для системи зондування ваш сервер виглядає як звичайний веб-сайт, а не як очевидна прокси-точка.
Уявіть це як носіння уніформи. Прикордонник, який інспектує транспортні засоби, не перевіряє кожну машину ретельно — він пропускає ті, які виглядають легітимно на основі їхної реєстрації, номерних знаків та зовнішності водія. Ваш трафік носить уніформу великої корпорації, тому мережевий інспектор пропускає його без детальної перевірки, яка розкрила б, що це насправді щось інше. Відбиток uTLS — це маскування, а обмін ключами x25519 — це таємний рукостиск, який знає тільки ваш клієнт.
Критична точка: вам не потрібен власний домен, щоб це працювало. Попередні методи stealth вимагали, щоб ви володіли доменом і отримали сертифікати Let’s Encrypt, що створювало слід паперу та додаткову складність. Reality потребує лише IP-адреси VPS. Цільові веб-сайти (Microsoft, Apple, Google) мають майже 100% час безперебійної роботи та підтримують найновіший протокол TLS 1.3, що робить їх ідеальними якорями для цієї техніки.
Порт 443 дає цьому маскуванню найкращий шанс змішатися. Стандартний HTTPS трафік зазвичай використовує порт 443, тому утримання Reality на цьому порту робить з’єднання набагато більш схожим на звичайний веб-серфінг. Інші порти можуть технічно працювати, але вони послаблюють маскування, оскільки вони більше не відповідають типовій формі повсякденного HTTPS трафіку.
Поширені помилкові уявлення
Перш ніж рухатися далі, давайте розберемося з трьома помилковими уявленнями, які заплутують людей, які вперше досліджують VLESS + Reality.
«VLESS — це VPN.» З технічної точки зору, VLESS — це протокол проксування, а не VPN у традиційному розумінні. Немає інтерфейсу TUN/TAP, немає віртуального мережевого адаптера та немає маніпуляцій таблицею маршрутизації. Однак з функціональної точки зору користувача він забезпечує саме те, чого ви очікуєте від VPN — ваш інтернет-трафік виглядає так, ніби він походить з IP-адреси сервера. Це розрізнення важливе для інженерів мереж, але рідко має значення для кінцевих користувачів.
«Reality потребує домену.» Це було правдою для попередніх методів приховування, які використовували власні домени та сертифікати Let’s Encrypt. Reality спеціально був розроблений для роботи без будь-якого домену, який ви контролюєте. Він використовує імітацію відбитків браузера та автентифікацію ключів x25519, що означає, що вам не потрібно реєструвати, керувати або поновлювати нічого. Налаштуйте один раз, і він продовжує працювати.
«Це неможливо зламати.» Нічого неможливо зламати. Reality дуже стійкий до виявлення та блокування, тому що він справді виглядає як звичайний HTTPS-трафік. Але він не захищений від майбутніх поліпшень у технології DPI, можливого розпізнавання відбитків протоколу або цільованих атак. Те, що він забезпечує, — це найкращий доступний захист у 2026 році від найпоширеніших форм фільтрації мережі. Розглядайте це як надійне рішення, а не як магічний щит.
Що вам потрібно перед початком
Вам потрібен VPS від будь-якого провайдера (наприклад, AvaHost), і подібні послуги також працюють добре. Для типової продуктивності одного користувача достатньо базового плану з 1 ядром CPU та 1 ГБ оперативної пам’яті. Сервер повинен працювати на Ubuntu 22.04 LTS або 24.04 LTS; ці версії мають вбудовану підтримку ядра для необхідних функцій мережі.
Root SSH доступ є обов’язковим. Вам потрібна можливість підключитися до вашого сервера через командний рядок та виконувати привілейовані команди. Більшість провайдерів VPS пропонують це за замовчуванням — після розгортання ви отримаєте IP-адресу, ім’я користувача (зазвичай root) та пароль або SSH ключ.
Для клієнтських додатків, залежно від ваших пристроїв, вам потрібні: v2rayNG для Android, v2rayN для Windows, V2Box або Streisand для macOS та Shadowrocket або FoXray для iOS. Ми розглянемо їх детально у розділі про клієнтські додатки далі в цьому посібнику.
Однією з суттєвих переваг методу Reality є те, що вам не потрібен домен, який ви контролюєте. Багато прихованих конфігурацій вимагають від вас реєстрації та управління доменом, але Reality може працювати безпосередньо з IP-адреси VPS, запозичуючи вигляд легітимного TLS призначення.
Коротка примітка щодо правових аспектів: Методи, описані в цьому посібнику, призначені для законних потреб приватності та доступу. Закони про фільтрацію інтернету значно відрізняються залежно від юрисдикції. Переконайтеся, що ваше використання цих інструментів відповідає чинному законодавству вашого регіону.
Підготовка сервера: BBR та основи
Після перевірки передумов давайте підготуємо сервер. Цей етап оптимізує ваш VPS перед встановленням будь-якого програмного забезпечення, забезпечуючи максимальну продуктивність з самого початку.
💡 ПОРАДА: Використовуйте BBR перед розгортанням — це часто покращує пропускну здатність і затримку на обмежених або високолатентних каналах.
Спочатку оновіть пакети системи. Це забезпечує наявність найновіших оновлень безпеки та необхідних залежностей:
apt update && apt upgrade -y
Цей крок може тривати 1–5 хвилин залежно від вашого постачальника VPS та швидкості мережі. Деякі постачальники попередньо оновлюють свої образи під час розгортання, тому на деяких системах це може завершитися швидко.
Далі увімкніть контроль перегруженості Google BBR. BBR (Bottleneck Bandwidth and Round-trip propagation time) — це алгоритм контролю перегруженості Google. Замість того щоб покладатися переважно на втрату пакетів як сигнал, він намагається безпосередньо моделювати доступну пропускну здатність і час циклу туди-назад, що може покращити пропускну здатність і чутливість на деяких VPS каналах.
# Verify BBR module is available
lsmod | grep tcp_bbr
Якщо нічого не з’являється, завантажте модуль вручну:
modprobe tcp_bbr
Тепер створіть конфігурацію sysctl для постійного увімкнення BBR:
cat >> /etc/sysctl.d/99-bbr.conf << 'EOF'
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF
Застосуйте конфігурацію:
sysctl -p /etc/sysctl.d/99-bbr.conf
Перевірте, що BBR активний:
sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_control
Ви повинні побачити bbr як активний алгоритм.
Деякі системи отримують користь від перезавантаження після увімкнення BBR — це забезпечує правильне завантаження модуля та вступ у силу всіх оптимізацій мережі:
reboot
Тепер переконайтеся, що порт 443 доступний. Якщо ви плануєте використовувати вбудований потік Let’s Encrypt інсталятора 3x-ui для панелі, дозвольте також 80/tcp — цей порт використовується для перевірки сертифіката ACME, а не для самої панелі. Якщо ваш постачальник VPS також має хмарний брандмауер або рівень групи безпеки, дозвольте там же ті ж порти. На Ubuntu найбезпечніший шлях — зазвичай UFW.
# If this is a remote VPS and you're enabling UFW for the first time, allow SSH before enabling the firewall
ufw allow OpenSSH
# Allow HTTPS-style Reality traffic
ufw allow 443/tcp
# Allow ACME validation for the 3x-ui panel's built-in Let's Encrypt setup
ufw allow 80/tcp
# Review rules, then enable only if UFW is not already active
ufw status
ufw enable
⚠️ ПОПЕРЕДЖЕННЯ: Порт 443 настійно рекомендується, оскільки він відповідає звичайному трафіку HTTPS. Інші порти можуть технічно працювати, але вони менш природно вписуються та роблять налаштування легшим для виявлення.
Ваш сервер тепер оптимізований і готовий до встановлення 3x-ui.
Встановлення панелі 3x-ui
Перед запуском інсталятора зверніть увагу на одну легко пропустити вимогу: якщо ви хочете, щоб вбудована установка Let’s Encrypt видала SSL-сертифікат для панелі, 80/tcp має бути відкритий і доступний з публічного інтернету. Цей порт валідації ACME відокремлений від порту панелі, який ви виберете під час установки.
Запустіть команду встановлення:
bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)
Поточні версії інсталятора не починаються зі старішого меню Install / Update / Uninstall, яке показують багато посібників. Замість цього скрипт одразу починає встановлення, встановлює будь-які відсутні залежності, завантажує найновіший реліз, а потім проводить вас через запити налаштування панелі.
Типовий потік встановлення тепер виглядає так:
- Виберіть, чи встановити користувацький порт панелі, чи дозволити інсталятору згенерувати випадковий.
- Дозвольте інсталятору згенерувати випадкові ім’я користувача, пароль і webBasePath.
- Виберіть, як налаштувати SSL панелі:
- 1 = Let’s Encrypt для домену
- 2 = Let’s Encrypt для IP-адреси сервера
- 3 = використовувати існуючий сертифікат
- Завершіть запити сертифіката, якщо ви використовуєте вбудований потік Let’s Encrypt.
⚠️ ВАЖЛИВО: Порт панелі не є тим самим, що порт валідації ACME. Ви можете запустити панель на випадковому порту, наприклад 13525, і все ще потребувати публічного 80/tcp відкритого, щоб Let’s Encrypt міг валідувати сертифікат.
Важливе правило просте: використовуйте точні облікові дані, шлях і URL, надруковані вашим власним інсталятором, а не припущення, скопійовані зі старіших посібників.
Ваш остаточний результат буде виглядати більше так:
Username: GENERATED_USERNAME Password: GENERATED_PASSWORD Port: 13525 WebBasePath: RANDOM_PATH Access URL: https://YOUR_SERVER_IP:13525/RANDOM_PATH
Перевірте, що служба працює:
systemctl status x-ui
Ця перевірка важлива. Звертайте особливу увагу на рядок веб-сервера у виводі статусу:
- Якщо ви бачите Web server running HTTPS …, SSL панелі працює правильно.
- Якщо ви бачите Web server running HTTP …, панель встановилася успішно, але налаштування SSL не завершилося.
Отримайте доступ до панелі, використовуючи точний URL, ім’я користувача та пароль, згенеровані вашим власним встановленням. Не припускайте, що шлях — це /panel, і не припускайте, що облікові дані — це admin/admin, якщо ваше власне встановлення явно не говорить про це.
💡 ПОРАДА 1: Щоб знову переглянути поточні параметри панелі та надрукувати URL доступу, у CLI запустіть команду “x-ui” і виберіть номер 10 “View Current Settings” з меню виводу.
💡 ПОРАДА 2: Якщо URL доступу не завантажується, переконайтеся, що порт панелі 3x-ui відкритий у брандмауері вашого VPS. Наприклад, якщо ваша панель працює на порту “13525”, дозвольте його за допомогою: ” ufw allow 13525/tcp “. Замініть 13525 на фактичний порт, який ви налаштували для панелі 3x-ui.
Якщо інсталятор завершується, але systemctl status x-ui показує HTTP замість HTTPS
Найпоширеніша причина — 80/tcp був недоступний з публічного інтернету під час валідації Let’s Encrypt. У цьому випадку панель все ще може встановитися і запуститися, але видача сертифіката не вдається.
Спочатку виправте брандмауер:
ufw allow 80/tcp
ufw status
Якщо ваш постачальник VPS має хмарний брандмауер або рівень групи безпеки, дозвольте 80/tcp там теж. Потім повторно запустіть налаштування сертифіката панелі зі скрипту управління 3x-ui:
x-ui
Для сертифіката панелі на основі IP виберіть:
- 19 → 6 (Get SSL for IP Address)
Для сертифіката панелі на основі домену виберіть:
- 19 → 1 (Get SSL (Domain))
Після видачі сертифіката перевірте знову:
systemctl status x-ui
Ви хочете, щоб вивід статусу показував Web server running HTTPS … перед тим, як продовжити.
💡 ПОРАДА: Одразу збережіть згенеровані облікові дані та URL панелі. Також зверніть увагу, що резюме інсталятора може бути оманливим, якщо видача сертифіката не вдається — якщо остаточний блок надруковує HTTPS URL, але systemctl status x-ui все ще показує HTTP, довіряйте виводу статусу служби і виправте SSL перед тим, як продовжити.
Налаштування VLESS + Reality Inbound
Це критичний крок конфігурації, на якому ваша VPN-подібна система фактично створюється. У панелі 3x-ui перейдіть до Inbounds → Add Inbound.
Налаштуйте поля таким чином:
| Поле | Значення | Примітки |
|---|---|---|
| Protocol | VLESS | Виберіть зі спадного меню |
| Listen IP | 0.0.0.0 | За замовчуванням / усі інтерфейси |
| Port | 443 | Рекомендується для найбільш природного маскування HTTPS |
| Client → Authentication | Залиште порожнім / за замовчуванням | Не використовуйте Get New keys для цього базового налаштування |
| Client → decryption | none | Обов’язково для VLESS |
| Client → encryption | none | Залиште за замовчуванням |
| Client → Flow | xtls-rprx-vision | Встановіть це в підрозділі Client. Якщо ви ще не бачите це поле, спочатку встановіть Transmission на TCP (RAW) і Security на reality. |
| Transmission | TCP (RAW) | Використовуйте прямий TCP-транспорт |
| Security | reality | Виберіть зі варіантів безпеки |
| uTLS | chrome | Використовуйте поширений браузерний відбиток |
| Target | www.microsoft.com:443 | Стабільна ціль TLS 1.3 для fallback/проб |
| SNI | www.microsoft.com | Тримайте узгодженою з Target |
| Short IDs | Згенеруйте або використовуйте за замовчуванням панелі | Скопіюйте одне згенероване значення на клієнт |
| SpiderX | / | Простий за замовчуванням |
| Public Key | Згенеруйте за допомогою Get New Cert | Скопіюйте це на клієнт |
| Private Key | Згенеруйте за допомогою Get New Cert | Тримайте це тільки на сервері |
📋 ПРИМІТКА: Залиште інші видимі поля — такі як Total Flow, Traffic Reset, Duration, Fallbacks, Proxy Protocol, HTTP Obfuscation, Sockopt, External Proxy, Show, Xver, Max Time Diff, Min Client Ver, Max Client Ver, Sniffing та ML-DSA поля — за їхніми значеннями за замовчуванням для цього базового налаштування.
Нарешті, натисніть Save, щоб створити inbound.
⚠️ ПОПЕРЕДЖЕННЯ: Порт 443 є найкращим за замовчуванням, оскільки він відповідає звичайному трафіку HTTPS. Якщо ви його змінюєте, inbound все ще може працювати, але він більше не змішується так чисто.
⚠️ ПОПЕРЕДЖЕННЯ: Ціль Reality повинна підтримувати TLS 1.3 — Microsoft, Apple та Google є безпечними варіантами. Використання цілі, яка не підтримує TLS 1.3, призведе до збою Reality, оскільки протокол розроблений спеціально для TLS 1.3 handshakes.
Причина, чому ці значення важливі: порт 443 дає вам найбільш переконливий профіль HTTPS, стабільна ціль TLS 1.3 дає пробам легітимне місце для приземлення, а відбиток chrome тримає клієнтську сторону узгодженою з одним з найпоширеніших браузерних відбитків в інтернеті. Почніть просто, отримайте один робочий шлях, а потім розширюйте пізніше, якщо вам потрібні кілька цілей.
Управління користувачами в 3x-ui
Після налаштування inbound потрібно створити користувацькі з’єднання, які ваші пристрої використовуватимуть для автентифікації. У 3x-ui перейдіть до Inbounds → [Клацніть на меню вашого VLESS inbound] → Add Client.
Кожен користувач отримує унікальний UUID (генерується автоматично), а також електронну адресу для ідентифікації та опціональні обмеження трафіку/терміну дії. Коли ви створюєте клієнта, панель генерує значення, необхідні для з’єднання: адреса сервера, UUID, flow, публічний ключ, short ID та параметри, пов’язані з SNI.
Натиснувши знак плюса (“+”) вибраного inbound, з’явиться список користувачів.
Експорт клієнта
Щоб експортувати деталі з’єднання одного клієнта, спочатку розгорніть рядок inbound, щоб була видима таблиця клієнтів. У рядку клієнта використовуйте дві дії експорту для кожного клієнта:
- Значок QR → відкриває модальне вікно QR
- Значок інформації → відкриває модальне вікно деталей
Вони відповідають першим двом методам спільного доступу.
QR-код: Клацніть на значок QR клієнта. Якщо підписки увімкнені, модальне вікно QR може показати два QR-коди:
- Subscription → QR для URL підписки клієнта
- Client QR (позначений електронною адресою клієнта або ідентифікатором, наприклад example@mail.com) → QR для прямого VLESS Reality URI
QR підписки корисний для клієнтів, які підтримують автоматичні оновлення. QR клієнта — це одноразовий прямий імпорт для цього конкретного клієнта.
Посилання для спільного доступу / URL: Клацніть на значок Info клієнта. У модальному вікні деталей ви можете побачити два типи текстового експорту:
- Subscription URL → оновлювана точка кінцевого підписки
- URL → прямий VLESS Reality URI для цього клієнта
Використовуйте кнопку копіювання поруч із розділом URL для імпорту на комп’ютер.
Як мінімум, придатний прямий Reality URI повинен містити заповнені значення, такі як:
type=tcp encryption=none security=reality sni=www.microsoft.com fp=chrome pbk=YOUR_PUBLIC_KEY sid=YOUR_SHORT_ID spx=/ flow=xtls-rprx-vision
pbk= — це публічний ключ Reality і повинен бути в прямому VLESS URI. Сам URL підписки зазвичай не містить pbk=, оскільки це лише точка кінцевого отримання; повернена конфігурація містить фактичні параметри Reality.
Деякі версії 3x-ui мали помилки в посиланнях на спільний доступ Reality, де pbk= був порожнім. Якщо прямому URI не вистачає pbk= або sid=, не довіряйте йому сліпо. У цьому випадку замість цього використовуйте ручне налаштування.
Ручне налаштування: Немає окремої кнопки експорту “ручної конфігурації”. На практиці ручне налаштування означає або введення значень безпосередньо в програму клієнта, або самостійне складання та перевірку остаточного VLESS Reality URI з необроблених значень. Зберіть необхідні значення з:
- модального вікна Infoадреса сервера, порт, UUID, flow та прямий URI
- параметрів Reality inboundSNI, публічний ключ, short ID, fingerprint (chrome) та SpiderX (/) за необхідності
Ви можете створити кількох користувачів для різних пристроїв або різних людей. Кожен UUID незалежний, тому відзив доступу для одного користувача не впливає на інших.
Ручна конфігурація Xray (Коротко)
Деякі користувачі віддають перевагу не використовувати графічний інтерфейс і хочуть редагувати конфігурацію Xray безпосередньо. При стандартному встановленні Linux 3x-ui активна конфігурація виконання записується в /usr/local/x-ui/bin/config.json, тому ви можете перевірити її або внести тимчасові ручні зміни там.
Розглядайте цей файл як згенерований артефакт виконання, а не як джерело істини панелі. 3x-ui перебудовує config.json зі своїх параметрів, підтримуваних базою даних, тому ручне редагування може бути перезаписано при перезавантаженні Xray або коли ви зберігаєте зміни в панелі.
Перед редагуванням створіть резервну копію:
cp /usr/local/x-ui/bin/config.json /usr/local/x-ui/bin/config.json.bak
Ручне редагування може бути корисним для швидкого тестування або налагодження, але неправильний JSON може зупинити запуск Xray. Якщо 3x-ui відповідає вашим потребам, дотримуйтесь панелі для постійних змін і використовуйте прямі редагування config.json тільки для розширених випадків.
Клієнтські додатки за платформами
Для підключення до вашого сервера вам потрібно встановити клієнтське програмне забезпечення на ваші пристрої. Ось що доступно:
| Платформа | Рекомендовані додатки | Примітки |
|---|---|---|
| Windows | v2rayN | GUI-клієнт з інтеграцією в системний трей |
| macOS | V2Box, Streisand | V2Box безплатний; Streisand доступний в App Store |
| Android | v2rayNG, NekoBox | Обидва доступні на GitHub та F-Droid |
| iOS | Shadowrocket, FoXray, V2Box | Shadowrocket платний; доступність FoXray може відрізнятися за регіонами |
Для Windows v2rayN — рекомендований вибір — він активно підтримується, має чистий інтерфейс і нативно підтримує конфігурацію Reality. Для мобільних пристроїв v2rayNG і V2Box обидва підтримують імпорт QR-кодів, що робить налаштування швидким.
📋 ПРИМІТКА: Доступність клієнтів для платформ Apple часто змінюється. Якщо перелічений додаток недоступний у вашому регіоні, перевірте офіційний сай
Підключення вашого першого клієнта
Давайте розглянемо процес підключення клієнта Windows за допомогою v2rayN — процес на інших платформах подібний, але це дає вам повний приклад.
Крок 1: Завантажте v2rayN
Відвідайте https://github.com/2dust/v2rayN/releases і завантажте поточну збірку Windows desktop. Станом на 2026 рік, найпростіший варіант — це зазвичай v2rayN-windows-64-desktop.zip (або поточний еквівалент пакета desktop, показаний на сторінці випусків).
Крок 2: Розпакуйте та запустіть
Розпакуйте ZIP у папку (наприклад, C:v2rayN). Запустіть v2rayN.exe. Останні збірки desktop зазвичай є самодостатніми, тому вам зазвичай не потрібно встановлювати окремий runtime .NET desktop. Програма з’являється в системному лотку.
Крок 3: Імпортуйте конфігурацію
Для цього підключення використовуйте прямий URL VLESS з 3x-ui — той, що починається з vless:// — а не URL підписки. Якщо ваше експортоване посилання Reality не містить необхідних значень, таких як pbk= або sid=, повертайтеся до попередньої секції 3x-ui і замість цього використовуйте ручні значення з параметрів inbound.
У v2rayN відкрийте меню Configuration у верхній лівій частині вікна. Найпростіший спосіб — скопіювати прямий URL VLESS з 3x-ui, а потім вибрати Configuration → Import Share Links from clipboard. На більшості збірок ви також можете просто натиснути Ctrl+V. Переконайтеся, що ви спочатку скопіювали прямий URL VLESS, щоб програма могла вставити значення.
Якщо імпорт через буфер обміну — не бажаний варіант, ви також можете використовувати QR-код або ручний імпорт.
Крок 4: Підключіться
Після імпорту клієнта, щоб активувати тунель між клієнтом Windows і сервером, натисніть “Enable tunnel” у нижній частині інтерфейсу v2rayN.
Крок 5: Перевірте
Відкрийте браузер і відвідайте https://whatismyipaddress.com/ або https://ip.sb. IP-адреса, яка відображається, повинна бути IP-адресою вашого сервера, а не вашою локальною IP-адресою. Це підтверджує, що ваш трафік маршрутизується через VPN.
Перевірка вашого налаштування
Перевірка з’єднання підтверджує, що все працює як очікується. Крім перевірки вашої IP-адреси в браузері, варто запустити кілька додаткових тестів.
Перевірка IP-адреси: Відвідайте https://whatismyipaddress.com/ або https://ip.sb під час підключення. Відображена IP-адреса повинна відповідати IP-адресі вашого VPS-сервера, а не вашій домашній або локальній мережевій IP-адресі.
Тест витоку DNS: Відвідайте https://dnsleak.com або https://browserleaks.com/dns та запустіть тест. Правильно налаштований клієнт не повинен розкривати ваші звичайні локальні DNS-резолвери під час активного проксі.
Поширені проблеми та рішення
Проблема Причина Рішення Немає з’єднання Порт 443 заблокований Перевірте firewall: ufw allow 443/tcp та консоль хмарного провайдера Панель не відкривається Неправильна URL або застаріле припущення про /panel Використовуйте точну HTTPS URL, надруковану інсталятором Імпортоване посилання не з’єднується У посиланні Reality відсутні pbk або sid Перевірте посилання або перейдіть на ручну конфігурацію клієнта Тайм-аут з’єднання Неправильний SNI Переконайтеся, що SNI збігається (www.microsoft.com) у параметрах клієнта Помилка TLS Неправильний відбиток або невідповідні значення Reality Встановіть відбиток на chrome і перевірте SNI, публічний ключ та короткий ID Низька швидкість BBR не увімкнений Повторно увімкніть BBR відповідно до розділу підготовки сервера «Немає відповіді від сервера» Firewall блокує Перевірте як firewall сервера, так і групи безпеки хмарного провайдера Наступні кроки та розширені опції
Тепер у вас є робочий VLESS + Reality VPN. Звідси доступні кілька вдосконалень:
- Обережно додайте резервний inboundЯкщо вам справді потрібен fallback, ви можете додати щось на кшталт VMess + WebSocket як вторинний inbound. Просто пам’ятайте, що кожен додатковий inbound збільшує складність і дає вам ще одну поверхню для захисту та усунення неполадок.
- Масштабування для кількох користувачівСтворіть додаткових клієнтів у 3x-ui для членів сім’ї або пристроїв. Кожен отримує унікальний UUID, і ви можете окремо відстежувати використання.
- Оптимізація продуктивностіBBR уже ввімкнено, але ви можете дослідити оптимізацію TCP/UDP, налаштування мережевих буферів і налаштування TCP на стороні сервера для незначних поліпшень.
- Альтернативні цілі SNIХоча Microsoft/Apple/Google є надійними, деякі користувачі віддають перевагу www.oracle.com або іншим цілям. Принцип залишається тим же — будь-який сайт з дійсними сертифікатами TLS 1.3 працює.
- Безпека панелі: Обмежте порт панелі своєю власною IP-адресою адміністратора, якщо це можливо, ротуйте облікові дані, якщо ви їх вибрали вручну, і розгляньте встанов
Висновок
VLESS + Reality — це потужний варіант self-hosted для 2026 року, якщо вам потрібна конфігурація, яка краще маскується, ніж традиційні VPN-протоколи. Його перевага — не магічна невидимість; це те, що трафік виглядає набагато ближче до звичайного зашифрованого веб-трафіку, ніж з’єднання OpenVPN або WireGuard на мережах із жорсткою фільтрацією.Якщо ви розумієте концептуальну модель — TLS fingerprinting, подібний до браузера, матеріал ключів Reality, правдоподібна ціль та стандартний HTTPS-порт — вам буде набагато легше розгортати, налагоджувати та обслуговувати конфігурацію. Звідси природні наступні кроки — посилення безпеки панелі, додавання більше клієнтських пристроїв та перевірка того, які цілі та клієнтські додатки найкраще працюють у вашому середовищі. Для хостингу провайдери, як-от AvaHost, можуть надати вам стабільну базу для запуску вашої конфігурації VLESS + Reality, забезпечуючи надійну доступність та просте управління.
Схожі публікації
