Эта статья - сборник разных вопросов и ответов на них, которые звучали в комментариях к моим предыдущим статьям (Современные технологии обхода блокировок: 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 вашего ) вел себя полностью идентично настоящему серверу, которым вы прикидываетесь. Если тот "настоящий" сервер слушает на 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 - я не пробовал, кто уже пользовался, расскажите, как оно.
Нет ли какого-нибудь решения с 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: маскироваться под сайт, пинг до которого от минимальный.
Более продвинутый способ: использовать утилиту от авторов 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."
Это известная проблема со стороны Гугла при доступе с некоторых по 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, поэтому ничего не сотрется.
Автор: Surrounded by idiots
