Эта статья - сборник разных вопросов и ответов на них, которые звучали в комментариях к моим предыдущим статьям (Современные технологии обхода блокировок: V2Ray, XRay, XTLS, Hysteria, Cloak и все-все-все, Bleeding-edge обход блокировок с полной маскировкой: настраиваем сервер и клиент XRay с XTLS-Reality быстро и просто и других из той же серии) и в личных сообщениях.

Разное

Пользуюсь прокси, и некоторые сервисы/приложения каким-то образом определяют, что я сижу через прокси, как они это делают?

Классических способов выявить прокси/VPN не так много, самые известные:

1) разница между часовыми поясами у клиента в браузере и в локации IP-адреса с которого он подключается (например, в браузере московский часовой пояс, а сервер в Лондоне и там пояс другой) - обойти элементарно;

2) выявление по MTU - ненадежно, актуально для OpenVPN/L2TP/Wireguard/SSTP, для XRay и подобных прокси не актуально, т.к. они работают на другом уровне;

3) сканирование IP клиента на предмет открытых стандартных портов (например, 443) - можно обойти цепочкой из двух серверов с туннелем между ними;

Если вы используете мобильное устройство, то банковское (или любое другое приложение) может смотреть, активен ли в системе VPN-интерфейс, либо сравнивать геолокацию устройства и локацию по IP-адресу. Некоторые особо тупые российские сервисы по умолчанию считают что "любой доступ из-за рубежа - значит включен VPN". И еще некоторые сервисы (типа Open AI) по умолчанию запрещают доступ с non-residental IP-адресов (то есть 99.9% VPS-хостеров).

Я настраиваю сервер с XTLS-Reality, как это сделать максимально правильно?

Суть Reality в маскировке под какой-либо популярный сайт, поэтому когда вы решаете это делать, вам нужно добиться того, чтобы ваш IP (IP вашего VPS) вел себя полностью идентично настоящему серверу, которым вы прикидываетесь. Если тот "настоящий" сервер слушает на 80-м порту (plain HTTP), то вам тоже нужно настроить nginx или правило фаервола, чтобы переадресовывать HTTP-запросы на оригинальный сервер. Если "настоящий" сервер не слушает SSH-подключения на стандартном 22-м порту, то ваш тоже не должен. Если ваш хостер предоставляет reverse-DNS записи для IP-адреса, убедитесь, что там не осталось значение по умолчанию (обычно с доменом хостера), а лучше задайте такой reverse-DNS, какой виден у IP-адреса ресурса, под который вы маскируетесь.

А почему рекомендуют избегать посещения через прокси зоны RU?

По закону Яровой у нас давно уже пишутся все метаданные интернет-активности (куда, когда, откуда были подключения, какие объемы данных передавались, и т.д.). В теории (но судя по тому, насколько часто встречается эти совет на китайских сайтах, у них это уже не в теории) возможно следующее: вы случайно (даже просто зайдя на какой-нибудь обычный сайт, который подгрузит скрипту или контент с другого сервера) через свой прокси делаете запрос на условный Яндекс/Мейл/ВК/Госуслуги. В логах метаданных видно: подключение от вас на какой-то внешний IP, и точно в тот же самый момент подключение с этого IP к сервису внутри страны (который, понятное дело, тоже подконтрольный), объемы переданных данных одинаковы (с учётом оверхеда протокола) - и после ряда таких совпадений можно однозначно сказать что на этом адресе работает прокси.

Либо ещё вариант: вы подключаетесь к сервису, сервис в ответ сканирует популярные порты IP-адреса с которого вы пришли, и видит там открытый 443 порт - тоже очень подозрительно, весьма вероятно что прокси, можно банить. Поэтому варианта два: или делать цепочку из двух прокси-серверов или один сервер с двумя разными адресами (сопоставить будет многократно сложнее), или создавать правила чтобы трафик от клиента до местных сайтов шел напрямую, а на прокси-сервере для надёжности резался.

Ну или мобильное приложение у вас на телефоне (имеющее доступ к геолокация или имени активной сотовой сети) видит что вы вроде внутри страны, но при этом подключение к их серверу происходит с какого-то иностранного адреса - тоже опачки :)

Что новенького появилось с момента обзора прокси-клиентов?

У Nekobox появилась русская локализация, а также в качестве ядра, помимо sing-box, там теперь можно использовать xray вместо безнадежно устаревшего v2ray.

Под Windows, macOS, Linux и Android появился многообещающий клиент Hiddify-Next, написанный на Flutter и основанный на Sing-box - у него очень простой интерфейс, работает хорошо, умеет автоматически пропускать напрямую трафик до ресурсов выбранной страны (Россия в списке тоже есть), не требуя дополнительной настройки маршрутов, поддерживает и прокси- и TUN-режимы, а ещё при получении списка серверов под подписке может пинговать их всех и автоматически использовать тот, который отвечает лучше всего. Название у него совпадает с названием известной панели, но по факту он может работать с любыми совместимыми серверами.

Под iOS появился новый клиент Streisand - я не пробовал, кто уже пользовался, расскажите, как оно.

А ещё новости из мира протоколов - вышла новая версия протокола Hysteria - Hysteria2. В Sing-box уже поддерживается.

Как цензоры умудряются заблокировать Shadowsocks даже версии 2022?

Согласно последнему GFW Report, детектировать Shadowsocks-2022 не умеют до сих пор даже китайцы, в итоге они просто в период обострений банят все протоколы, которые (не опознаны на DPI) AND (не похожи на простые текстовые).

В итоге получается прибить SS-соединения, пусть и ценой огромного collateral damage (побочных эффектов) - блокируются все неопознанные протоколы, то есть по сути дела мы имеем дело с белыми списками.

Кроме того, как заметили пользователи ntc.party "У SS есть одна особенность, запросы к серверу не мультиплексируются. Можно считать число подключений к паре адрес:порт и блокировать при превышении лимитов. Синтетические тесты такую блокировку не выявят. Например, при открытии браузером youtube, число установленных подключений к SS достигает 18, сам браузер открывает максимум 12 (числа взяты из эксперимента и могут отличаться)." Вывод - при работе через SS включайте мультиплексирование в клиенте. Клиент и сервер для этого должны быть одинаковые, потому что у XRay и Sing-box разные, не совместимые между собой механизмы мультиплексирования.

Нет ли какого-нибудь решения с VLESS, что бы завести к примеру 3х пользователей, но не пускать их в интернет, а раздать им доступы в разные внутренние сетки на контурах? Кажется 3Х-UI и подобные панели не умеют в разные приватные сети пользователей направлять.

3X-UI такое вроде не умеет, а голый XRay кажется настроить можно.
Сделать настройки Routing в конфиге, и в зависимости от ID пользователя, если destination IP совпадает с адресом разрешенной ему сети, то отправлять на соответствующий outbound'ы для этой сети, а все остальные запросы отправлять в block.
и в outbound'ах можно задать опцию sendthrough (https://xtls.github.io/en/config/outbound.html#outboundobject), чтобы трафик шел через правильный интерфейс.

Задержки 1100-1800 ms для Нидерландского сервера это норм для XTLS-Reality? Скорость не падает.

Да, норм. Два важных отличия от других технологий: 1) в отличие от VPN, где подключение к VPN-серверу устанавливается один раз и все, в случае с прокси, на каждое исходящее подключение из клиентского софта устанавливается новое подключение к прокси-серверу (если только не используется мультиплексирование) 2) поскольку через прокси невозможно послать ICMP-пинг, большинство клиентов меряют задержку не пингом, а выполнением HTTP-запроса.

Вот и считайте: когда вы запускаете тест, сначала устанавливается TCP-соединение с прокси-сервером (уже как минимум один, а то и два round-trip). Потом поверх него происходит TLS-хендшейк (ещё один round-trip), и в процессе него прокси-сервер ещё устанавливает TCP-соединение с reality-dest сервером и запрашивает у него сертификат. Потом прокси посылает запрос на установление TCP-соединения с тем сервером, который используется для теста. Потом, если URL указан как HTTPS, происходит ещё TLS-хендшейк с ним. Потом клиент делает HTTP-запрос и ждёт получения ответа. И только после ответа вы видите результат теста, и "задержка" - это суммарное время всего вышеописанного процесса.

Совет от@quakin:

Есть способ существенно уменьшить задержки для VLESS-Reality: маскироваться под сайт, пинг до которого от VPS минимальный.

Более продвинутый способ: использовать утилиту от авторов XTLS для выбора маскировочного сайта из той же подсети: RealiTLScanner.

Можно ли самого XRay/Sing-box завернуть подключения в корпоративный прокси для обхода ограничений интернета в организации? 

XRay и Sing-box умеют делать цепочки прокси.
В Sing-box, например, можно для каждого outbound'а задать "detour" (другой прокси), и таким образом достучаться до своего VLESS или Shadowsocks-сервера через корпоративный HTTP/SOCKS прокси. Если вы используете Nekobox,  то нужно создать в Nekobox одно подключение типа HTTP или SOCKS (для корпоративного прокси с его адресом). Потом создать отдельно ещё одно подключение, VLESS для вашего сервера.
И потом создать третье подключение типа Proxy Chain, и в него добавить первые два в нужном порядке.
Если корпоративный прокси суровый (перешифровывает TLS с подменой сертификатов), то чистый VLESS скорее всего не пропустит, но вполне может работать вариант с websocket-транспортом.

Что такое port-hopping?

Пользователи из Китая писали, что когда GFW банит подключения к их прокси-серверу, ограничения часто применяются только к конкретному используемому порту. В качестве обходного пути в этой ситуации можно использовать port hopping, когда прокси-сервер слушает сразу на сотнях портов, и подключаться можно к любому - это может быть очень полезно при использовании Shadowsocks.

Сделать это можно с помощью iptables DNAT:

iptables -t nat -A PREROUTING -i eth0 -p udp --dport 20000:50000 -j DNAT --to-destination :555
ip6tables -t nat -A PREROUTING -i eth0 -p udp --dport 20000:50000 -j DNAT --to-destination :555

В этом примере сервер слушает порт 555, но клиент может подключиться к любому порту в диапазоне 20000–50000.

Как понять, что у меня используется именно Shadowsocks-2022, а не старый классический Shadowsocks с уязвимостями?

В конфигурации клиента и сервера нужно использовать method который начинается с "2022-", например 2022-blake3-aes-128-gcm и 2022-blake3-aes-256-gcm (это стандартные), или 2022-blake3-chacha20-poly1305, 2022-blake3-chacha12-poly1305, 2022-blake3-chacha8-poly1305 (это extra).

Это все слишком сложно, можно как-то попроще?

Если все это слишком сложно - то советую Amnezia VPN, он устанавливается на любой сервер двумя кликами в понятном интерфейсе, есть клиенты под все платформы, и они тоже активно работают над защитой от выявления и блокирования.
Ну либо перемещать себя в юрисдикцию, где нет блокировок по протоколам.

Настройка маршрутизации и клиентов

Как настроить, чтобы на российские сервера и сайты доступ шел напрямую, без прокси?

Shadowrocket на iOS

На главном экране в пункте Global routing выбираем Config:

Далее идем на вкладку Config, там идем в General:

Скроллим ниже к Skip Proxy, и добавляем туда новый пункт "*.ru":

Сохраняем. Всё, готово.

Если нужен еще GeoIP, то чуть сложнее.

Идем на MaxMind Geolite2 и регистрируемся там: https://dev.maxmind.com/geoip/geolite2-free-geolocation-data

Как зарегались и залогинились - нажимаем Manage License Keys -> Create License Key. Он сгенерит новую лицензию - важно сразу сохранить Account ID и License Key, ключ целиком показывается в интерфейсе только один раз, потом еще раз посмотреть уже нельзя будет!

В Shadowrocket идем в Settings, там ищем Geolite2, и заполняем наши данные:

Нажимаем Update - он должен подтянуть актуальную базу.

Потом как и в прошлом пункте, на главном экране выбираем Global Routing - Config, идем в Config, и там не в General, а в Rules:

Жмем плюсик, и создаем новое правило с типом geoip, policy = direct, и country/area пишем "RU" (обязательно большим буквами, иначе не сработает):

Сохраняем, пользуемся.

Nekobox на Windows/Linux/MacOS

GeoIP активируется стандартным образом в Nekobox (не забудьте поставить sniffing mode в "used for routing!"):

Правила по суффиксам Nekobox не умеет, но их умеет sing-box в его основе, поэтому жмем "Custom" и прописываем

вот такое

{
    "rules": [
        {
            "domain_suffix": [
                ".ru"
            ],
            "outbound": "direct"
        }
    ]
}

После этого весь трафик до .ru-доменов и российских IP-адресов будет идти напрямую.

Если нужно заблокировать полностью - то в первом окне вместо Direct вставить в Block, а в JSON-коде исправить direct на block.

Nekobox Android

В Nekobox Android достаточно всего пару правил (раздельных, не два условия в одном правиле!), одного для доменов, другого для group.

И не забыть проверить, что в настройках включен sniffing:

Wings X / FoxRay iOS

Можно использовать только category-ru-gov , либол наоборот, не использовать ее, а прописать правила для всех .ru-доменов и российских IP как ниже

v2rayN Android

и в Custom rules вписать вот такое:

возможно вариант с доменом может привести к ложным срабатываниям для адресов типа www.rust.org, тогда можно оставить только geoip, для большинства случаев этого будет достаточно.

Можно ли автоматически использовать в прокси-клиенте списки "Антизапрета"?

Можно, ага. Качаете geoip.db и geosite.db вот отсюда: https://github.com/L11R/antizapret-sing-box-geo
И подсовываете их в ваш клиент. После этого настраиваете маршрутизацию как обычно, например, в качестве дефолтного маршрута выбираете bypass (direct), а через прокси пускаете IP-адреса по тегу geoip:antizapret и домены по тегуgeosites:antizapret

Также есть очень интересные списки на https://github.com/v2fly/domain-list-community

Столкнулся с проблемой, что проксируется только трафик браузера, трафик терминала, например, идёт мимо прокси

Это зависит от режима работы клиента.
В режиме system proxy устанавливается системный параметр, а вот использовать его или нет, зависит уже от самого приложения — браузеры его используют, а некоторые программы вообще не умеют и не хотят.
В режиме TUN заворачивается весь системный трафик, можно попробовать с ним, должно помочь.

Настроил правила роутинга в клиенте, но они, кажется, не работают - трафик все равно идет или весь напрямую, или весь на прокси, смотря что указано по умолчанию.

Надо смотреть настройки сниффинга в клиенте — во-первых он должен быть включен, и не AsIs, а что-то типа "Sniff for routing" или "Resolve Destination" (в зависимости от клиента):

Все включено, но роутинг все равно не работает как надо. Конфиг писал вручную.

У XRay есть специфика, там если заданы условия, по которым будет применять тот или иной роут (например, айпи назначения из такой-то подсети, inbound такой-то, протокол такой-то), то он применит этот роут только если все условия будут выполнены.
Ну и правила применяются сверху вниз, то есть первое правило которое полностью совпало, оно и будет использоваться

Я не использую никакие правила роутинга, но некоторые сайты все равно определяют мою реальную локацию, а не локацию прокси-сервера!

Если используется TUN-режим, в клиенте не включен IPv6 (на сервере - не важно), и при этом IPv6 предоставляется вашим провайдером - есть вероятность, что трафик до IPv4-ресурсов будет идти через прокси, а до IPv6-ресурсов - напрямую.

Это не проблема конкретно V2Ray/Xray/SS, это будет для любых прокси/VPN, работающих через TUN. Решение: включить IPv6 в клиенте (даже если сервер не поддерживает), либо отключить IPv6 на сетевом устройстве (LAN или WiFi).

На Гитхабе больше нет билдов Nekoray под MacOS :(

Есть неофициальные билды под мак:
https://github.com/aaaamirabbas/nekoray-macos/releases

Какие из прокси/VPN можно установить не имея прав администратора в Windows?

Большинство что консольных, что GUI клиентов Shadowsocks/Trojan/VLESS не требуют установки (достаточно кинуть файлы в папочку и запустить) и не требуют административного доступа. Но есть один нюанс: не получится работать через TUN-интерфейс (для установки драйвера и настройки сети нужны админские права), только через локальный прокси. Настройки прокси в винде, насколько я помню, может менять даже непривелигированный пользователь, и даже если админы запретили это делать, можно использовать браузер который не завязывается на системные настройки (например, Firefox точно так умеет).

Проблемы, ошибки, диагностика

С включенныи прокси не работают аудио-видео-звонки в месседжерах и онлайн-игры

Аудио- и видео- звонки, как и большинство игр, обычно используют передачу данных по UDP. VLESS/VMess/Shadowsocks поддерживают UDP, но у них есть проблемы с сохранением номера порта при реализации NAT, в результате чего могут быть проблемы. Для решения этих проблем разрабочики XRay придумали XUDP - специальное расширение протоколо, которое даст вам полноценный Full Cone NAT.

Как сделать, чтобы оно работало:
Если у вас и клиент и сервер на базе XRay свежих версий (1.8.3 и новее), то все должно работать автоматически.
Если у вас клиент на базе Sing-box (например, Nekobox), то надо явно в настройках подключения выбрать XUDP в параметре "Packet encoding".
Если у вас клиент на базе XRay, а сервер на базе Sing-box, то есть риск что ничего работать не будет, нужно менять клиент или сервер.

Клиент FoxRay на iPhone периодически вылетает, что делать?

В настройках FoxRay в меню Toolbox есть опция "reduce memory usage", возможно поможет.

Почему у клиентов теперь все предложения на YouTube, в браузере тоже хоть сбрасывай все настройки, показывает Тегеран. WTF?

Это загадка черной дыры, над которой мы долго ломали голову и так полностью и не разгадали.
У XRay совершенно точно трафик не прогоняется через какие-либо сервера ни в Иране, ни где-либо еще - это не то чтобы даже невозможно, но точно бессмысленно технически. В коде XRay ничего подобного нет.
Было подозрение что автор панели добавил в XRay какую-то отсебятину - проверили, в docker-образе оно собирается из исходников с гита, там никаких подозрительных патчей нет, и потом еще кто-то в комментариях к одной из старых статей пожаловался на такое же, только не про Иран, а про Китай :)
Для уверенности мы довольно долго смотрели в netstat и wireshark, вердикт - никаких левых подключений не делается.
Была теория, что возможно где-то в коде или конфигах захардкожены какие-нибудь региональные DNS-сервера (региональный сервер, резовля условный гугл и ютуб, может отдать его же адреса региональных зеркал и гугл с ютубом подумают, что вы оттуда) - опять же, в коде и конфигах ничего такого не нашлось.

Но есть еще одна теория.  Nekobox (возможно другие клиенты тоже, не проверял) в качестве "внутреннего" IPv6 адреса использует адрес из такого зарезервированного диапазона (ULA), где они должны генерироваться рандомно, и вероятность совпадения двух рандомных адресов ничтожна. То есть такой адрес должен быть уникальным, но в Nekobox он наоборот захардкожен один для всех случаев, и в итоге некоторые сервисы, которые могут каким-то образом получать и анализировать локальные адреса клиентов (например, Google с его телеметрией в Chrome и в Android), считают всех клиентов с таким внутренним адресом... одним и тем же клиентом, после чего сопоставляют их то ли с геолокацией, то ли с другими внутренними адресами, то ли и с тем и с тем, и в итоге в ряде случаев все пользователи Nekobox (и возможно других клиентов) для Гугла выглядят как пользователи откуда-то из Ирана, Китая или Азербайджана, вплоть до того, что со временем Гугл начинает считать публичный адрес прокси-сервера тоже иранским/китайским/etc, и это приводит к довольно забавным эффектам.

Варианты решения: не использовать TUN-режим (он же VPN mode), либо в правилах маршрутизации клиента или сервера запретить доступ до Google по IPv6, либо пропатчить клиент чтобы он использовал какой-нибудь другой внутренний адрес.

У меня FoXray не читает QR код (Shadowsocks-2022), пишет не корректные настройки. В то время этот же QR залетает в V2Box на ура. В чем может быть проблема, что я упустил? 

Если пытаетесь сканировать QR из X-UI панели — можно попробовать сначала добавить подключение оттуда по ссылке в локальный Nekoray, а уже оттуда пошарить QR. Ну и проверить, что в названии конфига и параметрах нет никаких лишних символов (кириллицы, амперсантов, вопросов, точек, лишних слешей, и т.д.)

Я в настройках клиента указал свой днс сервер на adguard home. В итоге у меня на сайтах проверки dnsleaktest.com светятся помимо моих днс резолверов еще и гугловские откуда-то…

Проверьте, что у вас в /etc/resolv.conf :)

Настраиваю Shadowsocks, при старте клиента или сервера ругается "illegal base64 data at input byte 3"

Что-то не то с ключом. Можно еще раз перегенерировать в панели (если используете панель), или с 'openssl rand -base64 16' или 'openssl rand -base64 32' (в зависимости от длины используемого шифра).

Пытаюсь запустить сервер, при запуске ругается "Failed to start: app/proxyman/inbound: failed to listen TCP on 443 > transport/internet: failed to listen on address: 0.0.0.0:443 > transport/internet/tcp: failed to listen TCP on 0.0.0.0:443 > listen tcp 0.0.0.0:443: bind: address already in use"

Ну ошибка говорит сама за себя: "address already in use" = на сервере на 443 порту запущен уже какой-то другой процесс. Можно посмотреть командой 'netstat -nlp' от рута, она покажет, какой процесс слушает какой порт.

Делаю netstat -nlp, и судя по всему, прокся слушает только на IPv6, чзх?

В линуксе выхлоп нетстата типа "tcp6 :::2323" обычно означает что сокет доступен и по IPv6, и по IPv4.
 

Пытаюсь запустить Nekoray под Windows, ругается на какие-то ошибки в библиотеках Qt

Если у вас старая версия Windows, то нужно использовать старые версии Nekoray — в новых уже нет поддержки Windows 7 (и Windows 8 кажется тоже).
Последняя такая версия — 3.17, файл называется "nekoray-3.17-2023-08-17-windows7-x64.zip".

Как точно определить, почему у меня клиент не подключается к серверу?

Увы, никак. В 99% случаев когда что-то не контачится, это будет какое-то несоответствие конфигурации между клиентом и сервером. Сам протокол сделан так, чтобы быть максимально недетектируемым, поэтому если серверу что-то не нравится (например, не совпал ключ пользователя, или еще что), то в ответ он не пришлет никаких ошибок чтобы не демаскировать себя, а будет молчать или рвать соединение - и остается только угадывать по логам.

Сделал все по инструкции, на сервере запустилась без ошибок, но прокси не работает. Nekobox говорит: "No connection could be made because the target machine actively refused it"

Ну собственно клиент говорит как есть — он не может подключиться к серверу. Либо на сервере не запущен процесс, либо фаервол на сервере блокирует подключения, либо фаервол на клиенте блокирует подключения, либо что-то не то с настройками.

Начать расследование можно с команды "netstat -nlp", которая покажет, действительно ли ваш прокси-сервер слушает входящие подключения, на каком именно IP и на каком порту.
Плюс проверьте конфигурацию фаервола согласно инструкциям для вашего дистрибутива, у некоторых дистрибутивов/хостеров по умолчанию есть правила, закрывающие все порты кроме явно разрешенных.

Также убедитесь, что вам не мешает локальный антивирус и его фаервол (например, некоторые жаловались на проблемы при наличии Касперского на клиентской машине).

В клиенте видны вот такие ошибки:

Похоже на протухшие системные корневые сертификаты из-за очень старой ОС без обновлений. Как вариант - попробовать поменять remote DNS в клиенте с https://8.8.8.8 на просто 8.8.8.8 или 1.1.1.1 (без https).

В NekoBox 3.18 на Macos режиме sing-box не активируется Tun Mode

https://github.com/abbasnaqdi/nekoray-macos/issues/36 -> 'sudo /Applications/nekoray_arm64.app/Contents/MacOS/nekoray'

На Android подписки заработали с v2rayNG, а с FoxRay на iOS нет

Без SSL-сертфиката и https-ссылки на подписку ничего не будет работать на iOS.

У меня сервер с XTLS-Vision или XTLS-Reality, при подключении с десктопа все работает, с мобильного устройства - нет, в чем может быть дело?

Проверьте настройки uTLS. Почему-то у многих клиентов при установке uTLS как "android" подключение фейлится, при установке uTLS как "chrome" - все работает. Не совсем понятно, это баг на стороне клиента или сервера, но баг интересный.

Использую Shadowsocks/Trojan/VLESS, и что-то скорость совсем не радует...

Настройте BBR на сервере, станет гораздо веселее:

echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p

либо более полный вариант тюнинга

net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.core.netdev_max_backlog = 10000
net.core.somaxconn = 4096
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_mem = 25600 51200 102400
net.ipv4.udp_mem = 25600 51200 102400
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
net.ipv4.tcp_mtu_probing = 1
net.ipv4.tcp_slow_start_after_idle=0

На некоторых системах модуль bbr может быть не загружен по умолчанию, если

# sysctl net.ipv4.tcp_available_congestion_control
не выдает в списке bbr:
net.ipv4.tcp_available_congestion_control = reno cubic hybla vegas yeah
необходимо добавить и ребутнуться:
echo “tcp_bbr” > /etc/modules‑load.d/modules.conf

При использовании SS/VLESS периодически перестает работать Google, выдает "That’s an error.Your client does not have permission to get URL / from this server. That’s all we know."

Это известная проблема со стороны Гугла при доступе с некоторых VPS по IPv6. Стоит попробовать отключить IPv6 в клиенте, если включен (обычно в настройках TUN-режима, если используете его), также в настройках DNS/роутинга выбрать PreferIPv4 если есть такая опция. Если ничего не помогает, то последний метод - если используете TUN-режим, то попробовать обычный прокси-режим, и наоборот.

Панели

Забыл логин или пароль 3X-UI, как восстановить?

Если подключен телеграм бот, то можно сделать бэкап конфига и бд, открываем .db файл блокнотом и ищем возможные части комбинаций пароля или логина.

Как обновить X-UI? Устанавливал через Docker

A: 1) Зайти в папку cd x-ui; 2) Потом остановить контейнер: 'docker-compose down' 3) Обновить, 'docker-compose pull xui'; 4) И запустить обратно docker-compose up -d
Готово. При этом тут в докер файле настройки и так хранятся в отдельном volume, поэтому ничего не сотрется.