From e9fb4de05b20e2a6d6a4c021afb0f35d5d159f2f Mon Sep 17 00:00:00 2001 From: Nikita Korotaev <104270279+iambabyninja@users.noreply.github.com> Date: Sat, 27 Dec 2025 15:09:02 +0500 Subject: [PATCH] sync RU docs (#789) * ECH and Sniffing: Explaining when to block QType 65 * Router: Clarifying the logic between GeoIP matchers * Explaining the impact of domainStrategy on happyEyeballs * Add link to inbound and outbound protocols * rewrite routing with dns tutorial + add images * rewrite dns page * Make proxySettings clearer * Metrics: Add goroutine pprof file requirement for memory issues * upd RU lang --- .vitepress/config.mts | 46 +-- docs/ru/config/dns.md | 277 ++++++++++--------- docs/ru/config/inbound.md | 7 +- docs/ru/config/metrics.md | 3 +- docs/ru/config/outbound.md | 30 +- docs/ru/config/outbounds/dns.md | 7 +- docs/ru/config/outbounds/freedom.md | 15 +- docs/ru/config/routing.md | 4 +- docs/ru/config/transport.md | 16 +- docs/ru/document/level-1/routing-with-dns.md | 244 +++++++++++----- 10 files changed, 374 insertions(+), 275 deletions(-) diff --git a/.vitepress/config.mts b/.vitepress/config.mts index 42386e8e..4edc2990 100644 --- a/.vitepress/config.mts +++ b/.vitepress/config.mts @@ -798,13 +798,13 @@ export default defineConfig({ { text: "Главная", link: "/ru" }, { text: "История сайта", link: "/ru/about/news.md" }, { - text: "Руководство по конфигурации", + text: "Описание функций", items: [ - { text: "Подробности функций", link: "/ru/config/features/" }, + { text: "Обзор", link: "/ru/config/features/" }, { text: "Базовая конфигурация", link: "/ru/config/" }, - { text: "Входящие протоколы", link: "/ru/config/inbounds/" }, - { text: "Исходящие протоколы", link: "/ru/config/outbounds/" }, - { text: "Нижние транспорты", link: "/ru/config/transports/" }, + { text: "Входящие подключения", link: "/ru/config/inbounds/" }, + { text: "Исходящие подключения", link: "/ru/config/outbounds/" }, + { text: "Транспортный уровень", link: "/ru/config/transports/" }, ], }, { @@ -812,11 +812,11 @@ export default defineConfig({ items: [ { text: "Быстрый старт", link: "/ru/document/" }, { - text: "Руководство для новичков простым языком", + text: "Простыми словами", link: "/ru/document/level-0/", }, - { text: "Советы для начинающих", link: "/ru/document/level-1/" }, - { text: "Продвинутые советы", link: "/ru/document/level-2/" }, + { text: "Базовые навыки", link: "/ru/document/level-1/" }, + { text: "Продвинутые навыки", link: "/ru/document/level-2/" }, ], }, { text: "Руководство разработчика", link: "/ru/development/" }, @@ -865,7 +865,7 @@ export default defineConfig({ sidebar: { "/ru/config/": [ { - text: "Подробности функций", + text: "Обзор", link: "/config/features/", collapsed: true, items: [ @@ -874,7 +874,7 @@ export default defineConfig({ link: "/ru/config/features/xtls.md", }, { - text: "Fallback (Возврат)", + text: "Fallback", link: "/ru/config/features/fallback.md", }, { @@ -896,32 +896,32 @@ export default defineConfig({ link: "/ru/config/", collapsed: true, items: [ - { text: "Настройка логов", link: "/ru/config/log.md" }, - { text: "API интерфейс", link: "/ru/config/api.md" }, + { text: "Настройка журнала", link: "/ru/config/log.md" }, + { text: "API", link: "/ru/config/api.md" }, { text: "Встроенный DNS-сервер", link: "/ru/config/dns.md" }, { text: "FakeDNS", link: "/ru/config/fakedns.md" }, - { text: "Входящий прокси", link: "/ru/config/inbound.md" }, + { text: "Входящие подключения", link: "/ru/config/inbound.md" }, { - text: "Исходящий прокси (Mux, XUDP)", + text: "Исходящие подключения", link: "/ru/config/outbound.md", }, - { text: "Локальная политика", link: "/ru/config/policy.md" }, + { text: "Локальные политики", link: "/ru/config/policy.md" }, { text: "Обратный прокси", link: "/ru/config/reverse.md" }, { text: "Маршрутизация", link: "/ru/config/routing.md" }, { text: "Статистика", link: "/ru/config/stats.md" }, { - text: "Транспорт (uTLS, REALITY)", + text: "Способы передачи", link: "/ru/config/transport.md", }, { text: "Метрики", link: "/ru/config/metrics.md" }, { - text: "Наблюдение за соединениями", + text: "Мониторинг подключений", link: "/ru/config/observatory.md", }, ], }, { - text: "Входящие протоколы", + text: "Входящие подключения", link: "/ru/config/inbounds/", collapsed: true, items: [ @@ -945,7 +945,7 @@ export default defineConfig({ ], }, { - text: "Исходящие протоколы", + text: "Исходящие подключения", link: "/ru/config/outbounds/", collapsed: true, items: [ @@ -978,7 +978,7 @@ export default defineConfig({ ], }, { - text: "Нижние транспорты", + text: "Способы передачи", link: "/ru/config/transports/", collapsed: true, items: [ @@ -1007,7 +1007,7 @@ export default defineConfig({ collapsed: true, items: [ { - text: "Скачать и установить", + text: "Загрузка и установка", link: "/ru/document/install.md", }, { text: "Настройка и запуск", link: "/ru/document/config.md" }, @@ -1019,7 +1019,7 @@ export default defineConfig({ ], }, { - text: "Руководство для новичков простым языком", + text: "Простыми словами", link: "/ru/document/level-0/", collapsed: true, items: [ @@ -1143,7 +1143,7 @@ export default defineConfig({ link: "/ru/development/intro/compile.md", }, { - text: "Цели дизайна", + text: "Дизайн", link: "/ru/development/intro/design.md", }, { diff --git a/docs/ru/config/dns.md b/docs/ru/config/dns.md index c7d0668d..0028fe4d 100644 --- a/docs/ru/config/dns.md +++ b/docs/ru/config/dns.md @@ -2,40 +2,42 @@ ## DNS-сервер -Встроенный DNS-модуль Xray имеет два основных назначения: +Встроенный модуль DNS в Xray имеет три основных назначения: -- На этапе маршрутизации: разрешает доменные имена в IP-адреса и выполняет сопоставление правил на основе полученных IP-адресов для разделения трафика. Разрешение доменных имен и разделение трафика зависят от значения `domainStrategy` в конфигурации модуля маршрутизации. Встроенный DNS-сервер будет использоваться для DNS-запросов только в том случае, если установлено одно из следующих двух значений: - - `"IPIfNonMatch"`: при запросе доменного имени выполняется сопоставление домена в маршрутизации, если совпадение не найдено, для этого доменного имени используется встроенный DNS-сервер для выполнения DNS-запроса, и возвращенный IP-адрес используется для повторного сопоставления IP-маршрутизации. - - `"IPOnDemand"`: при обнаружении любого правила на основе IP-адреса доменное имя немедленно разрешается в IP-адрес для сопоставления. +- На этапе маршрутизации (Routing): резолвинг доменов в IP и сопоставление правил на основе полученных IP для разделения трафика. Будет ли выполняться резолвинг и разделение трафика, зависит от значения `domainStrategy` в конфигурации модуля маршрутизации. Встроенный DNS-сервер используется для запросов только при установке следующих двух значений: + - "IPIfNonMatch": при запросе домена сначала выполняется сопоставление по правилам `domain`. Если совпадений нет, выполняется запрос к встроенному DNS-серверу для получения IP, после чего снова выполняется сопоставление правил маршрутизации по IP. + - "IPOnDemand": при обнаружении любого правила, основанного на IP, домен немедленно резолвится в IP для сопоставления. -- Разрешает целевой адрес для подключения. - - Например, если в исходящем подключении `freedom` установить `domainStrategy` равным `UseIP`, то запросы, отправленные этим исходящим подключением, сначала будут разрешены во встроенном сервере из доменного имени в IP-адрес, а затем будет выполнено подключение. - - Например, если в `sockopt` установить `domainStrategy` равным `UseIP`, то системные подключения, инициированные этим исходящим подключением, сначала будут разрешены во встроенном сервере из доменного имени в IP-адрес, а затем будет выполнено подключение. +- Резолвинг целевого адреса для подключения: + - Например, в `freedom` Outbound, если `domainStrategy` установлен в `UseIP`, запрос, исходящий из этого Outbound, сначала будет разрешен в IP через встроенный сервер, а затем произойдет подключение. + - Например, в `sockopt`, если `domainStrategy` установлен в `UseIP`, системное подключение, инициированное этим Outbound, сначала будет разрешено в IP встроенным сервером. -::: tip СОВЕТ 1 -DNS-запросы, отправляемые встроенным DNS-сервером, автоматически перенаправляются в соответствии с конфигурацией маршрутизации. +- Перехват DNS-трафика в режиме Transparent Proxy или работа в качестве рекурсивного DNS-сервера, открытого на порту 53. + +::: tip TIP 1 +DNS-запросы, отправляемые встроенным DNS-сервером, автоматически перенаправляются в соответствии с конфигурацией маршрутизации (Routing). ::: -::: tip СОВЕТ 2 -Поддерживаются только основные IP-запросы (записи A и AAAA), записи CNAME будут запрашиваться повторно до тех пор, пока не будет возвращена запись A/AAAA. Другие запросы не будут передаваться на встроенный DNS-сервер. +::: tip TIP 2 +Поддерживаются только базовые IP-запросы (записи A и AAAA). Записи CNAME будут запрашиваться повторно до тех пор, пока не будет возвращена запись A/AAAA. Другие типы запросов не попадают во встроенный DNS-сервер, а либо отбрасываются, либо передаются другим серверам в зависимости от вашей конфигурации Outbound. ::: ## Процесс обработки DNS -Если запрашиваемое доменное имя: +Если запрашиваемый домен: -- Совпадает с сопоставлением «доменное имя - IP», «доменное имя - массив IP» в `hosts`, то этот IP или массив IP возвращается в качестве результата разрешения DNS. -- Совпадает с сопоставлением «доменное имя - доменное имя» в `hosts`, то значение этого сопоставления (другое доменное имя) будет использоваться в качестве текущего запрашиваемого доменного имени, и процесс обработки DNS будет продолжаться до тех пор, пока не будет разрешен IP-адрес или возвращено пустое разрешение. -- Не совпадает с `hosts`, но совпадает с одним (несколькими) списками доменов `domains` на DNS-серверах, то в соответствии с приоритетом совпадающих правил, DNS-серверы, соответствующие этим правилам, будут использоваться для запроса по очереди. Если запрос к DNS-серверу не удался или `expectedIPs` не совпадает, то для запроса будет использоваться следующий DNS-сервер. В противном случае возвращается разрешенный IP-адрес. Если запрос ко всем совпадающим DNS-серверам не удался или `expectedIPs` не совпадает, то компонент DNS: - - По умолчанию выполнит «откат DNS-запроса (fallback)»: DNS-серверы, которые не использовались в предыдущем неудачном запросе и для которых `skipFallback` имеет значение по умолчанию `false`, будут использоваться для запроса по очереди. Если запрос не удался или `expectedIPs` не совпадает, то возвращается пустое разрешение; в противном случае возвращается разрешенный IP-адрес. - - Если `disableFallback` установлен в `true`, то «откат DNS-запроса (fallback)» выполняться не будет. -- Не совпадает ни с `hosts`, ни со списками доменов `domains` на DNS-серверах, то: - - По умолчанию DNS-серверы, для которых `skipFallback` имеет значение по умолчанию `false`, будут использоваться для запроса по очереди. Если запрос к первому выбранному DNS-серверу не удался или `expectedIPs` не совпадает, то для запроса будет использоваться следующий выбранный DNS-сервер. В противном случае возвращается разрешенный IP-адрес. Если запрос ко всем выбранным DNS-серверам не удался или `expectedIPs` не совпадает, то возвращается пустое разрешение. - - Если количество DNS-серверов, для которых `skipFallback` имеет значение по умолчанию `false`, равно 0 или `disableFallback` установлен в `true`, то для запроса будет использоваться первый DNS-сервер в конфигурации DNS. Если запрос не удался или `expectedIPs` не совпадает, то возвращается пустое разрешение; в противном случае возвращается разрешенный IP-адрес. +- Попадает в маппинг «домен - IP» или «домен - массив IP» в `hosts`, то этот IP или массив возвращается как результат DNS-резолвинга. +- Попадает в маппинг «домен - домен» в `hosts`, то значение (другой домен) становится текущим запрашиваемым доменом и снова проходит процесс обработки DNS, пока не будет получен IP или пустой ответ. +- Не попал в `hosts`, но попал в список доменов `domains` одного (или нескольких) DNS-серверов, то запрос выполняется через эти серверы в порядке приоритета правил. Если запрос к выбранному серверу не удался или `expectedIPs` не совпали, используется следующий подходящий сервер; в противном случае возвращается полученный IP. Если все подходящие серверы не смогли выполнить запрос или `expectedIPs` не совпали, компонент DNS: + - По умолчанию выполняет «DNS Fallback запрос»: последовательно опрашиваются серверы, которые «не использовались в предыдущем неудачном раунде и имеют `skipFallback` со значением по умолчанию `false`». Если запрос не удался или `expectedIPs` не совпали, возвращается пустой ответ; иначе — полученный IP. + - Если `disableFallback` установлено в `true`, «DNS Fallback запрос» не выполняется. +- Не попал ни в `hosts`, ни в списки `domains` DNS-серверов, то: + - По умолчанию последовательно используются «серверы с `skipFallback` по умолчанию `false`». Если первый выбранный сервер не смог выполнить запрос или `expectedIPs` не совпали, используется следующий; иначе возвращается IP. Если все выбранные серверы потерпели неудачу, возвращается пустой ответ. + - Если количество «серверов с `skipFallback` по умолчанию `false`» равно 0 или `disableFallback` установлено в `true`, используется первый DNS-сервер из конфигурации. При неудаче возвращается пустой ответ, при успехе — IP. ## DnsObject -`DnsObject` соответствует элементу `dns` в файле конфигурации. +`DnsObject` соответствует разделу `dns` в конфигурационном файле. ```json { @@ -72,8 +74,11 @@ DNS-запросы, отправляемые встроенным DNS-серве "clientIp": "1.2.3.4", "queryStrategy": "UseIP", "disableCache": false, + "serveStale": false, + "serveExpiredTTL": 0, "disableFallback": false, "disableFallbackIfMatch": false, + "enableParallelQuery": false, "useSystemHosts": false, "tag": "dns_inbound" } @@ -82,74 +87,63 @@ DNS-запросы, отправляемые встроенным DNS-серве > `hosts`: map{string: address} | map{string: [address]} -Статический список IP-адресов, значением которого является серия "доменное имя": "адрес" или "доменное имя": ["адрес 1","адрес 2"]. Где адрес может быть IP-адресом или доменным именем. При разрешении доменного имени, если доменное имя соответствует элементу в этом списке: +Список статических IP. Значениями являются пары "домен": "адрес" или "домен": ["адрес 1","адрес 2"]. Адрес может быть IP или доменом. При резолвинге, если домен совпадает с записью в этом списке: -- Если адрес элемента является IP-адресом, то результатом разрешения будет IP-адрес этого элемента. -- Если адрес элемента является доменным именем, то для разрешения IP-адреса будет использоваться это доменное имя, а не исходное доменное имя. -- Если в адресе установлено несколько IP-адресов и доменных имен, то будет возвращено только первое доменное имя, остальные IP-адреса и доменные имена будут проигнорированы. -- Когда первым значением в адресе стоит символ решётки с числом (например, `#3`), то при исходящих запросах DNS ядро вернёт пустой ответ и rcode с указанным номером, отклоняя запрос; если же запрос был внутренним, он будет просто считаться неудачным. +- Если адрес является IP, результатом будет этот IP. +- Если адрес является доменом, для получения IP будет использоваться этот новый домен, а не исходный. +- Если в адресе указано несколько IP и доменов, будет возвращен только первый домен, остальные IP и домены игнорируются. +- Если первое значение адреса начинается с решетки и цифры (например, `#3`), при использовании DNS Outbound ядро вернет пустой ответ и соответствующий `rcode` (код отказа), чтобы отклонить запрос. Если запрос пришел из внутреннего источника, он будет считаться неудачным. +- Если запрашиваемый домен совпадает с несколькими доменами в списке, возвращаются все связанные IP. -Формат доменного имени может быть следующим: - -- Простая строка: правило вступает в силу, если эта строка полностью совпадает с целевым доменным именем. Например, "xray.com" соответствует "xray.com", но не соответствует "www.xray.com". -- Регулярное выражение: начинается с `"regexp:"`, остальная часть является регулярным выражением. Правило вступает в силу, если это регулярное выражение соответствует целевому доменному имени. Например, "regexp:\\\\.goo.\*\\\\.com\$" соответствует "www.google.com", "fonts.googleapis.com", но не соответствует "google.com". -- Поддомен (рекомендуется): начинается с `"domain:"`, остальная часть является доменным именем. Правило вступает в силу, если это доменное имя является целевым доменным именем или его поддоменом. Например, "domain:xray.com" соответствует "www.xray.com" и "xray.com", но не соответствует "wxray.com". -- Подстрока: начинается с `"keyword:"`, остальная часть является строкой. Правило вступает в силу, если эта строка соответствует любой части целевого доменного имени. Например, "keyword:sina.com" может соответствовать "sina.com", "sina.com.cn" и "www.sina.com", но не соответствует "sina.cn". -- Предопределенный список доменов: начинается с `"geosite:"`, остальная часть является именем, например, `geosite:google` или `geosite:cn`. Имена и списки доменов см. в разделе [Предопределенные списки доменов](./routing.md#предопределенные-списки-доменов). +Формат сопоставления (`domain:`, `full:` и т.д.) аналогичен `domain` в системе [маршрутизации](./routing.html#ruleobject). Отличие в том, что без префикса здесь по умолчанию используется `full:` (аналогично стандартному файлу hosts). > `servers`: \[string | [DnsServerObject](#dnsserverobject) \] -Список DNS-серверов, поддерживается два типа: DNS-адрес (в виде строки) и [DnsServerObject](#dnsserverobject). +Список DNS-серверов. Поддерживаются два типа: адрес DNS (строка) и [DnsServerObject](#dnsserverobject). -Значение `"localhost"` означает использование предустановленной конфигурации DNS на локальной машине. +Если значение `"localhost"`, используется конфигурация DNS локальной системы. -Если значением является DNS-адрес `"IP:Порт"`, например, `"8.8.8.8:53"`, Xray будет использовать указанный UDP-порт этого адреса для DNS-запросов. Этот запрос следует правилам маршрутизации. Если порт не указан, по умолчанию используется порт 53. +Если значение — адрес DNS `"IP:Port"`, например, `"8.8.8.8:53"`, Xray будет использовать указанный UDP-порт этого адреса для DNS-запроса. Запрос следует правилам маршрутизации. Если порт не указан, по умолчанию используется 53. -Если значение имеет вид `"tcp://хост:порт"`, например, `"tcp://8.8.8.8:53"`, Xray будет использовать `DNS over TCP` для запроса. Этот запрос следует правилам маршрутизации. Если порт не указан, по умолчанию используется порт 53. +Если значение в формате `"tcp://host:port"`, например, `"tcp://8.8.8.8:53"`, Xray будет использовать `DNS over TCP`. Запрос следует правилам маршрутизации. По умолчанию порт 53. -Если значение имеет вид `"tcp+local://хост:порт"`, например, `"tcp+local://8.8.8.8:53"`, Xray будет использовать `локальный режим TCP (TCPL)` для запроса. Это означает, что DNS-запрос не будет проходить через компонент маршрутизации, а будет отправляться непосредственно через исходящее подключение Freedom, чтобы сократить время ожидания. Если порт не указан, по умолчанию используется порт 53. +Если значение в формате `"tcp+local://host:port"`, например, `"tcp+local://8.8.8.8:53"`, Xray будет использовать `TCP Local Mode (TCPL)`. DNS-запрос не проходит через компонент маршрутизации, а отправляется напрямую через Freedom outbound для снижения задержек. По умолчанию порт 53. -Если значение имеет вид `"https://хост:порт/dns-query"`, например, `"https://dns.google/dns-query"`, Xray будет использовать `DNS over HTTPS` (RFC8484, сокращенно DOH) для запроса. Некоторые провайдеры имеют сертификаты с псевдонимами IP-адресов, можно напрямую указывать IP-адрес, например, `https://1.1.1.1/dns-query`. Также можно использовать нестандартные порты и пути, например, `"https://a.b.c.d:8443/my-dns-query"`. +Если значение в формате `"https://host:port/dns-query"`, например, `"https://dns.google/dns-query"`, Xray будет использовать `DNS over HTTPS` (RFC8484, сокращенно DoH). Некоторые провайдеры имеют сертификаты для IP-адресов, поэтому можно указывать IP напрямую, например, `https://1.1.1.1/dns-query`. Также можно использовать нестандартные порты и пути, например, `"https://a.b.c.d:8443/my-dns-query"`. -Если значение имеет вид `"h2c://хост:порт/dns-query"`, например, `"h2c://dns.google/dns-query"`, Xray будет использовать формат запроса `DNS over HTTPS`, но отправит его в виде открытого текста h2c. Нельзя использовать напрямую. В этом случае необходимо самостоятельно настроить исходящее соединение Freedom + streamSettings, установив TLS, чтобы обернуть его в обычный DOH-запрос. Используется для особых целей, например, когда требуется настроить SNI для DOH-запроса или использовать отпечаток utls. +Если значение в формате `"h2c://host:port/dns-query"`, например, `"h2c://dns.google/dns-query"`, Xray будет использовать формат запроса `DNS over HTTPS`, но отправит его в открытом виде (h2c). Это нельзя использовать напрямую; требуется настроить Freedom Outbound + streamSettings с TLS, чтобы обернуть запрос в нормальный DoH. Используется для специальных целей, например, для настройки SNI в DoH-запросе или использования `utls` отпечатков. -Если значение имеет вид `"https+local://хост:порт/dns-query"`, например, `"https+local://dns.google/dns-query"`, Xray будет использовать `локальный режим DOH (DOHL)` для запроса. Это означает, что DOH-запрос не будет проходить через компонент маршрутизации, а будет отправляться непосредственно через исходящее подключение Freedom, чтобы сократить время ожидания. Обычно подходит для использования на сервере. Также можно использовать нестандартные порты и пути. +Если значение в формате `"https+local://host:port/dns-query"`, например, `"https+local://dns.google/dns-query"`, Xray будет использовать `DoH Local Mode (DOHL)`. DoH-запрос не проходит через компонент маршрутизации, а отправляется напрямую через Freedom outbound. Обычно подходит для использования на сервере. Поддерживаются нестандартные порты и пути. -Если значение имеет вид `"quic+local://хост"`, например, `"quic+local://dns.adguard.com"`, Xray будет использовать `локальный режим DNS over QUIC (DOQL)` для запроса. Это означает, что DNS-запрос не будет проходить через компонент маршрутизации, а будет отправляться непосредственно через исходящее подключение Freedom. Этот метод требует, чтобы DNS-сервер поддерживал DNS over QUIC. По умолчанию для запроса используется порт 853, можно использовать нестандартный порт. +Если значение в формате `"quic+local://host"`, например, `"quic+local://dns.adguard.com"`, Xray будет использовать `DNS over QUIC Local Mode (DOQL)`. DNS-запрос не проходит через компонент маршрутизации, а отправляется напрямую через Freedom outbound. Требуется поддержка DNS over QUIC сервером. По умолчанию используется порт 853, можно указать нестандартный. -Если значением является `fakedns`, то для запроса будет использоваться функция FakeDNS. +Если значение `fakedns`, используется функционал FakeDNS. -::: tip СОВЕТ 1 -При использовании `localhost` DNS-запросы локальной машины не контролируются Xray, для того чтобы DNS-запросы перенаправлялись Xray, требуется дополнительная настройка. +::: tip TIP 1 +При использовании `localhost` DNS-запросы системы не контролируются Xray. Требуется дополнительная настройка, чтобы перенаправить системные DNS-запросы в Xray. ::: -::: tip СОВЕТ 2 -Инициализированные DNS-клиенты для различных правил отображаются в журнале запуска Xray с уровнем `info`, например, режимы `local DOH`, `remote DOH` и `udp`. +::: tip TIP 2 +DNS-клиенты, инициализированные различными правилами, будут отображаться в логе запуска Xray с уровнем `info`, например, режимы `local DOH`, `remote DOH` и `udp`. ::: -::: tip СОВЕТ 3 -(v1.4.0+) Вы можете включить ведение журнала DNS-запросов в [журнале](./log.md). +::: tip TIP 3 +(v1.4.0+) В [логах](./log.md) можно включить журналирование DNS-запросов. ::: > `clientIp`: string -Используется для указания IP-адреса клиента при отправке DNS-запросов на сервер. Не может быть приватным адресом. +IP-адрес, используемый в расширении EDNS Client Subnet (ECS). -::: tip СОВЕТ 1 -Требуется, чтобы DNS-сервер поддерживал EDNS Client Subnet. -::: - -::: tip СОВЕТ 2 -Вы можете указать `clientIp` для всех DNS-серверов в [DnsObject](#dnsobject), а также указать `clientIp` для каждого DNS-сервера в конфигурации [DnsServerObject](#dnsserverobject) (приоритет выше, чем у конфигурации [DnsObject](#dnsobject)). -::: +Должен быть валидным IPv4 или IPv6. При фактической отправке последние биты автоматически стираются: отправляются подсети /24 для IPv4 и /96 для IPv6. > `queryStrategy`: "UseIP" | "UseIPv4" | "UseIPv6" | "UseSystem" -Значение по умолчанию `UseIP` запрашивает как записи A, так и записи AAAA. `UseIPv4` запрашивает только записи A; `UseIPv6` запрашивает только записи AAAA. +Ограничивает возможности всех серверов в модуле DNS, а также задает значение по умолчанию для типов IP-запросов, инициированных самим Xray. -`UseSystem`: при каждом DNS-запросе выполняется проверка системной сети на предмет поддержки IPv6 (и IPv4). Если она поддерживает IPv6 (или IPv4), то адреса IPv6 (или IPv4) также возвращаются, в противном случае — нет. +Значение по умолчанию `UseIP` разрешает запросы A + AAAA. Если тип IP не указан в запросе, инициированном самим Xray, у вышестоящего DNS-сервера запрашиваются одновременно A и AAAA записи. `UseIPv4` запрашивает и разрешает только A записи; `UseIPv6` запрашивает и разрешает только AAAA записи. -Новая функция в Xray-core v1.8.6: `queryStrategy` можно установить отдельно для каждого `DNS` сервера. +`UseSystem` адаптируется к сетевой среде операционной системы. Перед запросом проверяется наличие шлюзов по умолчанию для IPv4 и IPv6, чтобы ограничить возможности серверов и установить тип запроса. В ОС с графическим интерфейсом проверка выполняется в реальном времени, в среде командной строки — только один раз. ```json "dns": { @@ -161,7 +155,7 @@ DNS-запросы, отправляемые встроенным DNS-серве "geosite:netflix" ], "skipFallback": true, - "queryStrategy": "UseIPv4" // запрос записей A для домена netflix + "queryStrategy": "UseIPv4" // Для доменов netflix запрашивать A запись }, { "address": "https://1.1.1.1/dns-query", @@ -169,27 +163,26 @@ DNS-запросы, отправляемые встроенным DNS-серве "geosite:openai" ], "skipFallback": true, - "queryStrategy": "UseIPv6" // запрос записей AAAA для домена openai + "queryStrategy": "UseIPv6" // Для доменов openai запрашивать AAAA запись } ], - "queryStrategy": "UseIP" // запрос записей A и AAAA для всех остальных доменов + "queryStrategy": "UseIP" // Глобально запрашивать одновременно A и AAAA записи } ``` -::: tip СОВЕТ 1 -Глобальное значение `"queryStrategy"` имеет приоритет. Если значение `"queryStrategy"` в дочернем элементе конфликтует с глобальным значением `"queryStrategy"`, запрос дочернего элемента вернет пустой ответ. +::: tip TIP 1 +Глобальное значение `"queryStrategy"` имеет приоритет. Если `"queryStrategy"` во вложенном элементе конфликтует с глобальным `"queryStrategy"`, запрос вложенного элемента вернет пустой ответ. ::: -::: tip СОВЕТ 2 -Если параметр `"queryStrategy"` не указан в дочернем элементе, используется значение глобального параметра `"queryStrategy"`. Поведение аналогично версиям Xray-core до v1.8.6. +::: tip TIP 2 +Если параметр `"queryStrategy"` во вложенном элементе не указан, используется глобальное значение `"queryStrategy"`. Поведение аналогично версиям Xray-core до v1.8.6. ::: -Например: - -Глобальное значение `"queryStrategy": "UseIPv6"` конфликтует с дочерним значением `"queryStrategy": "UseIPv4"`. -Глобальное значение `"queryStrategy": "UseIPv4"` конфликтует с дочерним значением `"queryStrategy": "UseIPv6"`. -Глобальное значение `"queryStrategy": "UseIP"` не конфликтует с дочерним значением `"queryStrategy": "UseIPv6"`. -Глобальное значение `"queryStrategy": "UseIP"` не конфликтует с дочерним значением `"queryStrategy": "UseIPv4"`. +Например:
+Глобальный `"queryStrategy": "UseIPv6"` и вложенный `"queryStrategy": "UseIPv4"` — конфликт.
+Глобальный `"queryStrategy": "UseIPv4"` и вложенный `"queryStrategy": "UseIPv6"` — конфликт.
+Глобальный `"queryStrategy": "UseIP"` и вложенный `"queryStrategy": "UseIPv6"` — не конфликтуют.
+Глобальный `"queryStrategy": "UseIP"` и вложенный `"queryStrategy": "UseIPv4"` — не конфликтуют. ```json "dns": { @@ -201,143 +194,161 @@ DNS-запросы, отправляемые встроенным DNS-серве "geosite:netflix" ], "skipFallback": true, - "queryStrategy": "UseIPv6" // конфликт между глобальным значением "UseIPv4" и дочерним значением "UseIPv6" + "queryStrategy": "UseIPv6" // Конфликт: глобальный "UseIPv4" и "UseIPv6" вложенного элемента } ], "queryStrategy": "UseIPv4" } ``` -Запрос домена netflix вернет пустой ответ из-за конфликта значений `"queryStrategy"`. Запись A для домена netflix будет получена от `https://1.1.1.1/dns-query`. +Запрос домена Netflix получит пустой ответ из-за конфликта значений `"queryStrategy"`. Домен Netflix будет запрошен через `https://1.1.1.1/dns-query` и получит запись A. > `disableCache`: true | false -`true` отключает кэширование DNS, по умолчанию `false`, то есть кэширование включено. +`true` отключает кэширование DNS. По умолчанию `false` (не отключено). -Этот параметр не влияет на DNS для `localhost`, который всегда использует системный кэш DNS. +Это не влияет на `localhost` DNS (системный DNS), который всегда следует поведению кэширования DNS в Golang (cgo и pure go могут немного отличаться). + +> `serveStale`: true | false + +`true` включает оптимистичное кэширование DNS (DNS optimistic caching). По умолчанию `false` (не включено). + +Работает только если кэширование включено на сервере (зависит от `disableCache`). + +> `serveExpiredTTL`: number + +Срок жизни оптимистичного кэша в секундах. По умолчанию 0 (никогда не истекает). + +Если сервер использует кэш и включено оптимистичное кэширование: когда основной кэш истек, но оптимистичный кэш еще действителен, немедленно возвращается устаревшая запись DNS из кэша, а обновление кэша происходит в фоновом режиме. Это снижает Latency. > `disableFallback`: true | false -`true` отключает откат DNS-запросов (fallback), по умолчанию `false`, то есть откат включен. +`true` отключает fallback-запросы DNS. По умолчанию `false` (не отключено). > `disableFallbackIfMatch`: true | false -`true` отключает откат DNS-запросов (fallback), если сработал список доменов с приоритетным сопоставлением для DNS-сервера, по умолчанию `false`, то есть откат включен. +`true` отключает fallback-запросы, если сработал список приоритетных доменов DNS-сервера. По умолчанию `false` (не отключено). + +> `enableParallelQuery`: true | false + +`true` включает параллельные запросы. По умолчанию `false` (не включено). + +Отказоустойчивость (failover) DNS по умолчанию последовательна: запрос к следующему серверу отправляется только после неудачи предыдущего или несовпадения `expectedIPs` / `unexpectedIPs`. + +При включении параллельных запросов они отправляются асинхронно ко всем выбранным DNS-серверам, и применяется стратегия «Динамическая группировка, гонка внутри группы, откат между группами». + +**Динамическая группировка**: **соседние** серверы в списке выбранных считаются одной группой, если их параметры `clientIP`, `skipFallback`, `queryStrategy`, `tag`, `domains`, `expectedIPs`, `unexpectedIPs` **полностью** совпадают. + +**Гонка внутри группы**: если любой DNS-сервер в группе успешно выполнил запрос и полученный IP соответствует `expectedIPs` / `unexpectedIPs`, группа считается успешной. Результаты остальных серверов группы игнорируются. + +**Откат между группами**: пока первая группа выполняет запрос, система ждет. Если первая группа успешна — возвращается IP. Если все серверы первой группы потерпели неудачу или IP не подошел — происходит откат (fallback) к следующей группе. Если все группы потерпели неудачу, возвращается пустой ответ. > `useSystemHosts`: true | false -Если установлено значение `true`, системные хосты добавляются к хостам, определённым в конфигурации, при запуске. Значение по умолчанию — `false`. +Если `true`, системный файл hosts добавляется к hosts встроенного DNS. > `tag`: string -Трафик запросов, отправляемых встроенным DNS, за исключением режимов `localhost`, `fakedns`, `TCPL`, `DOHL` и `DOQL`, можно сопоставить в маршрутизации с помощью `inboundTag` по этому тегу. +Для трафика запросов, исходящих от встроенного DNS (кроме режимов `localhost`, `fakedns`, `TCPL`, `DOHL` и `DOQL`), можно использовать этот тег для сопоставления в маршрутизации через `inboundTag`. ### DnsServerObject ```json { - "tag": "dns-tag", "address": "1.2.3.4", "port": 5353, "domains": ["domain:xray.com"], "expectedIPs": ["geoip:cn"], "unexpectedIPs": ["geoip:cloudflare"], "skipFallback": false, + "finalQuery": false, + "tag": "dns-tag", "clientIP": "1.2.3.4", "queryStrategy": "UseIPv4", - "timeoutMs": 4000, - "disableCache": false, - "finalQuery": false + "disableCache": false } ``` -> `tag`: string - -Тег этого DNS-сервера. Если задан, этот тег будет использоваться как `inbound tag` при отправке запросов (не в локальном режиме), переопределяя глобальную опцию `tag`. - > `address`: address -Список DNS-серверов, поддерживается два типа: DNS-адрес (в виде строки) и DnsServerObject. +Список DNS-серверов. Поддерживаются два типа: адрес DNS (строка) и DnsServerObject. -Значение `"localhost"` означает использование предустановленной конфигурации DNS на локальной машине. +Если значение `"localhost"`, используется конфигурация DNS локальной системы. -Если значением является DNS-адрес `"IP"`, например, `"8.8.8.8"`, Xray будет использовать указанный UDP-порт этого адреса для DNS-запросов. Этот запрос следует правилам маршрутизации. По умолчанию используется порт 53. +Если значение — адрес DNS `"IP"`, например, `"8.8.8.8"`, Xray будет использовать указанный UDP-порт этого адреса для DNS-запроса. Запрос следует правилам маршрутизации. По умолчанию используется порт 53. -Если значение имеет вид `"tcp://хост"`, например, `"tcp://8.8.8.8"`, Xray будет использовать `DNS over TCP` для запроса. Этот запрос следует правилам маршрутизации. По умолчанию используется порт 53. +Если значение в формате `"tcp://host"`, например, `"tcp://8.8.8.8"`, Xray будет использовать `DNS over TCP`. Запрос следует правилам маршрутизации. По умолчанию порт 53. -Если значение имеет вид `"tcp+local://хост"`, например, `"tcp+local://8.8.8.8"`, Xray будет использовать `локальный режим TCP (TCPL)` для запроса. Это означает, что DNS-запрос не будет проходить через компонент маршрутизации, а будет отправляться непосредственно через исходящее подключение Freedom, чтобы сократить время ожидания. Если порт не указан, по умолчанию используется порт 53. +Если значение в формате `"tcp+local://host"`, например, `"tcp+local://8.8.8.8"`, Xray будет использовать `TCP Local Mode (TCPL)`. DNS-запрос не проходит через компонент маршрутизации, а отправляется напрямую через Freedom outbound для снижения задержек. Если порт не указан, по умолчанию используется 53. -Если значение имеет вид `"https://хост:порт/dns-query"`, например, `"https://dns.google/dns-query"`, Xray будет использовать `DNS over HTTPS` (RFC8484, сокращенно DOH) для запроса. Некоторые провайдеры имеют сертификаты с псевдонимами IP-адресов, можно напрямую указывать IP-адрес, например, `https://1.1.1.1/dns-query`. Также можно использовать нестандартные порты и пути, например, `"https://a.b.c.d:8443/my-dns-query"`. +Если значение в формате `"https://host:port/dns-query"`, например, `"https://dns.google/dns-query"`, Xray будет использовать `DNS over HTTPS` (RFC8484, сокращенно DoH). Некоторые провайдеры имеют сертификаты для IP-адресов, поэтому можно указывать IP напрямую, например, `https://1.1.1.1/dns-query`. Также можно использовать нестандартные порты и пути, например, `"https://a.b.c.d:8443/my-dns-query"`. -Если значение имеет вид `"https+local://хост:порт/dns-query"`, например, `"https+local://dns.google/dns-query"`, Xray будет использовать `локальный режим DOH (DOHL)` для запроса. Это означает, что DOH-запрос не будет проходить через компонент маршрутизации, а будет отправляться непосредственно через исходящее подключение Freedom, чтобы сократить время ожидания. Обычно подходит для использования на сервере. Также можно использовать нестандартные порты и пути. +Если значение в формате `"https+local://host:port/dns-query"`, например, `"https+local://dns.google/dns-query"`, Xray будет использовать `DoH Local Mode (DOHL)`. DoH-запрос не проходит через компонент маршрутизации, а отправляется напрямую через Freedom outbound для снижения задержек. Обычно подходит для использования на сервере. Поддерживаются нестандартные порты и пути. -Если значение имеет вид `"quic+local://хост:порт"`, например, `"quic+local://dns.adguard.com"`, Xray будет использовать `локальный режим DOQ (DOQL)` для запроса. Это означает, что DNS-запрос не будет проходить через компонент маршрутизации, а будет отправляться непосредственно через исходящее подключение Freedom. Этот метод требует, чтобы DNS-сервер поддерживал DNS over QUIC. По умолчанию для запроса используется порт 853, можно использовать нестандартный порт. +Если значение в формате `"quic+local://host:port"`, например, `"quic+local://dns.adguard.com"`, Xray будет использовать `DOQ Local Mode (DOQL)`. DNS-запрос не проходит через компонент маршрутизации, а отправляется напрямую через Freedom outbound. Требуется поддержка DNS over QUIC сервером. По умолчанию используется порт 853, можно указать нестандартный. -Если значением является `fakedns`, то для запроса будет использоваться функция FakeDNS. +Если значение `fakedns`, используется функционал FakeDNS. -::: tip О режиме local и доменных именах самих DNS-серверов -DNS-запросы, отправленные модулем DNS, делятся на два типа: +::: tip О режиме local и доменах самих DNS-серверов +DNS-запросы, отправляемые модулем DNS, бывают двух типов: -В режиме **local** подключение будет осуществляться напрямую через ядро. В этом случае, если адрес является доменным именем, его обработка будет передана самой системе, что делает логику относительно простой. +Режим `local`: соединение устанавливается ядром напрямую во внешнюю сеть. Если адрес является доменом, он будет разрешен самой системой. Логика здесь проста. -В режиме, отличном от **local**, запросы по умолчанию рассматриваются как входящие от входного тега с `dns.tag` (где это? Найдите в тексте браузера с помощью ctrl+f «inboundTag»). Эти запросы проходят через стандартный процесс обработки ядра, и, возможно, будут направлены маршрутизирующим модулем либо на локальный **freedom**, либо на другие удалённые выходные соединения. В этом случае запрос будет либо разрешён с использованием **domainStrategy** модуля **freedom** (обратите внимание на возможность зацикливания), либо передан в виде доменного имени на удалённый сервер, где он будет разрешён в соответствии с настройками сервера. +Режим `non-local`: по умолчанию запрос рассматривается как входящий из Inbound с тегом `dns.tag` (не знаете где это? нажмите `ctrl+f` в браузере и найдите `inboundTag`). Он проходит через стандартный процесс обработки ядра и может быть направлен модулем маршрутизации в локальный `freedom` или другой удаленный Outbound. Там он будет разрешен согласно `domainStrategy` в `freedom` (осторожно, возможна петля) или передан в удаленный узел в виде домена для разрешения согласно методу сервера. -Поскольку обычным пользователям может быть сложно разобраться в этой логике, рекомендуется (особенно в условиях прозрачного прокси) напрямую задавать IP-адреса для DNS-серверов с доменными именами в параметре **host** модуля DNS, чтобы избежать зацикливания. +Поскольку обычным пользователям сложно разобраться в этой логике, рекомендуется (особенно в среде Transparent Proxy) напрямую указывать соответствующие IP для серверов с доменными именами в опции `hosts` модуля DNS, чтобы предотвратить возникновение петель (loop). -Кроме того, DNS-запросы, отправленные модулем DNS в режиме, отличном от **local**, автоматически пропускают обработку **IPIfNonMatch** и **IPOnDemand** в маршрутизирующем модуле, чтобы избежать зацикливания из-за их возможной отправки обратно в модуль DNS. +Кстати, DNS-запросы в режиме `non-local` автоматически пропускают этапы резолвинга `IPIfNonMatch` и `IPOnDemand` в модуле маршрутизации, чтобы их резолвинг не был отправлен обратно в модуль DNS, вызывая бесконечный цикл. ::: > `port`: number -Порт DNS-сервера, например, `53`. Если этот элемент не указан, по умолчанию используется значение `53`. Этот элемент не используется в режимах DOH, DOHL, DOQL, нестандартный порт должен быть указан в URL. +Порт DNS-сервера, например `53`. Если не указано, по умолчанию `53`. Для режимов DOH, DOHL, DOQL этот параметр недействителен; нестандартные порты следует указывать в URL. > `domains`: \[string\] -Список доменов. Домены из этого списка будут в первую очередь запрашиваться через этот сервер. Формат доменного имени такой же, как и в [конфигурации маршрутизации](./routing.md#ruleobject). +Список доменов. Домены из этого списка будут приоритетно запрашиваться через данный сервер. Формат доменов аналогичен [конфигурации маршрутизации](./routing.md#ruleobject). > `expectedIPs`:\[string\] -Список диапазонов IP-адресов, формат такой же, как и в [конфигурации маршрутизации](./routing.md#ruleobject). +Список диапазонов IP. Формат аналогичен [конфигурации маршрутизации](./routing.md#ruleobject). -Если этот элемент настроен, Xray DNS будет проверять возвращаемые IP-адреса и возвращать только адреса, входящие в список `expectedIPs`. +Если этот параметр настроен, Xray DNS проверит возвращенный IP и вернет его только в том случае, если он входит в список `expectedIPs`. -Если этот элемент не настроен, IP-адреса будут возвращены как есть. +Если в списке присутствует `*`, и после фильтрации IP не найден, будет возвращен исходный IP, чтобы запрос не завершился ошибкой. -если вы добавите "\*" в этот список, исходные IP-адреса все равно будут возвращены, если ни один IP-адрес не совпадет. +> `unexpectedIPs`: [string] -> `unexpectedIPs`: \[string\] - -Противоположность `expectedIPs`. IP-адрес считается совпавшим тогда и только тогда, когда он не совпадает ни с одним из диапазонов IP-адресов в списке. Другими словами: -`expectedIPs = [0.0.0.0/0, ::/0] - unexpectedIPs.` - -если вы добавите "\*" в этот список, исходные IP-адреса все равно будут возвращены, если ни один IP-адрес не совпадет. +Обратная версия `expectedIPs`. Исключает IP, входящие в этот список. Звездочка работает так же. > `skipFallback`: true | false -`true` - этот сервер будет пропущен при выполнении отката DNS-запроса (fallback), по умолчанию `false`, то есть сервер не будет пропущен. - -> `finalQuery`: true | false - -Если `true`, результат запроса возвращается в любом случае (даже если список IP-адресов пуст), и никакой другой запасной вариант (fallback) не будет выполнен. - -> `disableCache`: true | false - -Если `true`, кеш отключается только для этого DNS-сервера. - -Этот параметр не влияет на DNS для `localhost`, который всегда использует системный кеш DNS. +`true` — пропускать этот сервер при выполнении DNS fallback запросов. По умолчанию `false` (не пропускать). > `timeoutMs`: number -Тайм-аут DNS-сервера, по умолчанию 4000 мс. +Таймаут DNS-сервера. По умолчанию 4000 мс. -Этот параметр не влияет на DNS для `localhost`, который всегда использует системный тайм-аут DNS. +Это не влияет на `localhost` DNS (системный DNS), который всегда следует поведению таймаута DNS в Golang (cgo и pure go могут немного отличаться). -> `tag`: string +> `finalQuery`: true | false -Тег этого DNS-сервера. Если он установлен, то будет использоваться как тег входящего соединения для инициации запроса (в нелокальном режиме), переопределяя глобальный параметр тега. +Если `true`, запрос к этому DNS-серверу будет последней попыткой; fallback не будет инициирован. > `queryStrategy`: "UseIP" | "UseIPv4" | "UseIPv6" | "UseSystem" -`UseIPv4` запрашивает только записи A; `UseIPv6` запрашивает только записи AAAA. Значение по умолчанию — `UseIP`, которое запрашивает и A, и AAAA записи. +Если не указано, наследуется из глобальной конфигурации. Если указано, позволяет дополнительно ограничить возможности этого сервера, а также задать значение по умолчанию для типов IP-запросов, инициированных самим Xray. -`UseSystem`: при каждом DNS-запросе выполняется проверка системной сети на предмет поддержки IPv6 (и IPv4). Если поддерживается IPv6 (или IPv4), то адреса IPv6 (или IPv4) также возвращаются, в противном случае — нет. +Внимание: этот параметр всегда ограничен глобальным `queryStrategy`. + +### Следующие параметры, если не указаны, наследуются из глобальной конфигурации, но могут переопределять её здесь + +> `tag`: string + +> `clientIP`: [string] + +> `disableCache`: true | false + +> `serveStale`: true | false + +> `serveExpiredTTL`: number \ No newline at end of file diff --git a/docs/ru/config/inbound.md b/docs/ru/config/inbound.md index 9a390a20..c142ee7a 100644 --- a/docs/ru/config/inbound.md +++ b/docs/ru/config/inbound.md @@ -61,8 +61,7 @@ > `protocol`: "dokodemo-door" | "http" | "shadowsocks" | "mixed" | "vless" | "vmess" | "trojan" | "wireguard" -Название протокола подключения. -Список доступных протоколов см. в разделе "Входящие подключения" в левой части документации. +Название протокола соединения. Список доступных протоколов см. в разделе [Входящие протоколы](./inbounds/) в меню слева. > `settings`: InboundConfigurationObject @@ -96,7 +95,9 @@ Так как запрос теперь направляется на abc.com, можно выполнять больше действий, например, повторное разрешение DNS, помимо разделения трафика по доменным правилам. -Если в sniffing включен параметр `enabled`, Xray также сможет обнаруживать трафик типа bittorrent, а затем можно настроить правила маршрутизации по протоколу, чтобы обрабатывать трафик BT, например, блокировать его на сервере или перенаправлять его на определенный VPS на клиенте. +Если в `sniffing` параметр `enable` установлен в `true`, можно также распознавать трафик типа `bittorrent`. Затем в модуле Routing можно настроить поле `"protocol"` для обработки незашифрованного BT-трафика. Например, на сервере можно блокировать незашифрованный BT-трафик, а на клиенте — статически перенаправлять его на определенный VPS. + +Внимание: Новые браузеры могут использовать ECH (Encrypted Client Hello). В этом случае Xray видит только домен в Outer Hello. Возможно, потребуется рассмотреть вариант DNS Hijacking или ручного отключения ECH в настройках браузера. ### SniffingObject diff --git a/docs/ru/config/metrics.md b/docs/ru/config/metrics.md index 68e73357..be214b01 100644 --- a/docs/ru/config/metrics.md +++ b/docs/ru/config/metrics.md @@ -29,8 +29,7 @@ Перейдите по адресу `http://127.0.0.1:11111/debug/pprof/` или используйте `go tool pprof` для отладки. -Для сообщения о проблемах с чрезмерным использованием памяти/утечками памяти необходимо предоставить файл `/debug/pprof/heap`. - +Для сообщения о проблемах с высоким потреблением памяти или утечками памяти необходимо предоставить файлы `/debug/pprof/heap` и `/debug/pprof/goroutine`. ### expvars Перейдите по адресу `http://127.0.0.1:11111/debug/vars`. diff --git a/docs/ru/config/outbound.md b/docs/ru/config/outbound.md index 68e53661..40f8bd06 100644 --- a/docs/ru/config/outbound.md +++ b/docs/ru/config/outbound.md @@ -21,7 +21,8 @@ "tag": "тег", "streamSettings": {}, "proxySettings": { - "tag": "another-outbound-tag" + "tag": "another-outbound-tag", + "transportLayer": false }, "mux": {} } @@ -45,10 +46,9 @@ Xray будет использовать случайный IP-адрес из Как и в описании для `inbound`, из-за особенностей `UDP` как протокола без установления соединения, `Xray` не может определить исходный целевой `IP`-адрес запроса, поступающего в ядро (например, в рамках одного и того же `QUIC`-соединения он может даже меняться), поэтому эта функция не может работать. -> `protocol`: string +> `protocol`: "blackhole" | "dns" | "freedom" | "http" | "loopback" | "shadowsocks" | "socks" | "trojan" | "vless" | "vmess" | "wireguard" -Название протокола подключения. -Список доступных протоколов см. в разделе "Исходящие подключения" в левой части документации. +Название протокола соединения. Список доступных протоколов см. в разделе [Исходящие протоколы](./outbounds/) в меню слева. > `settings`: OutboundConfigurationObject @@ -69,8 +69,7 @@ Xray будет использовать случайный IP-адрес из > `proxySettings`: [ProxySettingsObject](#proxysettingsobject) -Настройки исходящего прокси. -Если исходящий прокси включен, параметр `streamSettings` этого исходящего подключения игнорируется. +Конфигурация Outbound-прокси. > `mux`: [MuxObject](#muxobject) @@ -80,26 +79,25 @@ Xray будет использовать случайный IP-адрес из ```json { - "tag": "another-outbound-tag" + "tag": "another-outbound-tag", + "transportLayer": false } ``` > `tag`: string -При указании тега другого исходящего подключения данные, отправляемые этим исходящим подключением, будут перенаправлены через указанное исходящее подключение. +Если указан тег другого Outbound, данные, исходящие из этого Outbound, будут перенаправлены через указанный Outbound. ::: danger -Этот способ пересылки **не использует** транспортный уровень. -Если вам нужна пересылка с использованием транспортного уровня, используйте [SockOpt.dialerProxy](./transport.md#sockoptobject). +Эта опция конфликтует с [SockOpt.dialerProxy](./transport.md#sockoptobject), используйте только один из этих вариантов по необходимости. + +По умолчанию этот метод перенаправления **не проходит** через транспортный уровень (REALITY/XHTTP/gRPC...), то есть `streamSettings` данного Outbound не будут иметь эффекта.
+Если вам требуется перенаправление с поддержкой транспортного уровня, используйте `SockOpt.dialerProxy` или установите `transportLayer` в `true`. ::: -::: danger -Этот параметр несовместим с SockOpt.dialerProxy. -::: +> `transportLayer`: true | false -::: tip -Совместим с настройкой `transportLayer` в v2fly/v2ray-core [transportLayer](https://www.v2fly.org/config/outbounds.html#proxysettingsobject). -::: +`true` преобразует эту настройку в `SockOpt.dialerProxy` для поддержки перенаправления на транспортном уровне. По умолчанию `false` (преобразование не выполняется). ### MuxObject diff --git a/docs/ru/config/outbounds/dns.md b/docs/ru/config/outbounds/dns.md index 8816c2de..d1679349 100644 --- a/docs/ru/config/outbounds/dns.md +++ b/docs/ru/config/outbounds/dns.md @@ -38,10 +38,9 @@ DNS — это исходящий протокол, который в основ > `blockTypes`: array -Массив целых чисел, блокирующий типы запросов, указанные в массиве. Например, `"blockTypes":[65,28]` блокирует запросы типа 65 (HTTPS) и 28 (AAAA). +Массив целых чисел (`int`), определяющий типы DNS-запросов, которые необходимо блокировать. Например, `"blockTypes": [65,28]` означает блокировку типа 65 (HTTPS) и 28 (AAAA). Распространенный сценарий использования — блокировка типа 65 для предотвращения инициализации ECH браузерами. -Поскольку `nonIPQuery` по умолчанию отклоняет все запросы, не относящиеся к A и AAAA, необходимо установить для него значение `skip`, чтобы этот параметр заработал. Конечно, можно и не менять, а использовать его только для блокировки запросов A или AAAA, чтобы блокировать запросы IPv4/IPv6, но это крайне не рекомендуется. Рекомендуется настроить соответствующие параметры в `queryStrategy` встроенного DNS-сервера. - -Примечание: когда `blockTypes` используется только для блокировки A или AAAA, если `nonIPQuery` установлен в `reject`, то способом блокировки также будет возврат DNS reject, а не отбрасывание запроса. +Поскольку опция `nonIPQuery` по умолчанию отбрасывает (`drop`) все запросы, кроме A и AAAA, необходимо переключить её в режим `skip`, чтобы данная настройка могла вступить в силу (для типов, отличных от A/AAAA). Разумеется, можно не изменять `nonIPQuery` и использовать эту опцию исключительно для блокировки A или AAAA (отключение IPv4/IPv6), однако делать это **крайне не рекомендуется**. Для этих целей лучше использовать настройку `queryStrategy` во встроенном DNS. +Внимание: если вы используете `blockTypes` только для блокировки A или AAAA, и при этом `nonIPQuery` установлен в значение `reject`, то блокировка также будет осуществляться путем возврата ответа DNS reject, а не простым отбрасыванием пакета. ## Примеры конфигурации DNS diff --git a/docs/ru/config/outbounds/freedom.md b/docs/ru/config/outbounds/freedom.md index bafe56c3..ac5edf16 100644 --- a/docs/ru/config/outbounds/freedom.md +++ b/docs/ru/config/outbounds/freedom.md @@ -31,20 +31,11 @@ Freedom — это исходящий протокол, который можн Значение по умолчанию — `"AsIs"`. -Когда целевым адресом является доменное имя, при настройке соответствующих значений Freedom будет вести себя следующим образом: +Все параметры по смыслу аналогичны `domainStrategy` в [sockopt](../transport.md#sockoptobject). -- При использовании `"AsIs"`, Xray будет напрямую использовать приоритет подключений по умолчанию в Golang. По некоторым причинам, UDP-соединения, использующие доменное имя, игнорируют системные настройки приоритета IPv4. +Только использование `AsIs` в этом разделе позволяет передать доменное имя в последующий модуль `sockopt`. Если установить значение, отличное от `AsIs`, домен будет разрешен в конкретный IP, что сделает последующие настройки `sockopt.domainStrategy` и связанный с ними механизм `happyEyeballs` недействительными. (Если вы не изменяли эти настройки, негативного влияния не будет). -- При указании других значений для разрешения будет использоваться [встроенный DNS-сервер](../dns.md) Xray-core. Если `DNSObject` не существует, будет использоваться системный DNS. Если имеется несколько подходящих IP-адресов, ядро случайным образом выберет один из них в качестве целевого IP-адреса. -- `"IPv4"` означает попытку установить соединение, используя только IPv4, `"IPv4v6"` означает попытку соединения с использованием IPv4 или IPv6, но для доменов с двойным стеком будет использоваться IPv4. _(Если поменять местами v4 и v6, логика остается аналогичной)_ - -- Если в настройках встроенного DNS указан `"queryStrategy"`, фактическое поведение будет объединено с этим параметром, и будут разрешаться только те типы IP, которые указаны в обоих параметрах. Например, `"queryStrategy": "UseIPv4"` и `"domainStrategy": "UseIP"` фактически эквивалентны `"domainStrategy": "UseIPv4"`. -- При использовании параметров, начинающихся с `"Use"`, если результат разрешения не соответствует требованиям (например, доменное имя имеет только запись A, но используется `UseIPv6`), будет выполнен откат к `AsIs`. -- При использовании параметров, начинающихся с `"Force"`, если результат разрешения не соответствует требованиям, соединение установить не удастся. - -::: tip СОВЕТ 1 -При использовании режимов `"UseIP"` или `"ForceIP"` и указании `sendThrough` в [конфигурации исходящего соединения](../outbound.md#outboundobject), Freedom будет автоматически определять необходимый тип IP-адреса (IPv4 или IPv6) на основе значения `sendThrough`. Если вручную указан только один тип IP-адреса (например, `UseIPv4`), но он не соответствует локальному адресу, указанному в `sendThrough`, подключение установить не удастся. -::: +По определенным причинам при отправке UDP протокол Freedom игнорирует `domainStrategy` в `sockopt` и по умолчанию принудительно отдает предпочтение IPv4. > `redirect`: address_port diff --git a/docs/ru/config/routing.md b/docs/ru/config/routing.md index 311c4c65..7689cd9f 100644 --- a/docs/ru/config/routing.md +++ b/docs/ru/config/routing.md @@ -95,8 +95,8 @@ - IP-адрес: например, `"127.0.0.1"`. - [CIDR](https://ru.wikipedia.org/wiki/Бесклассовая_междоменная_маршрутизация): например, `"10.0.0.0/8"`, также можно использовать `"0.0.0.0/0"` `"::/0"` для указания всех IPv4- или IPv6-адресов. - Предопределенный список IP-адресов: этот список встроен в каждый установочный пакет Xray, имя файла - `geoip.dat`. Формат использования: `"geoip:код_страны"`, должно начинаться с `geoip:` (в нижнем регистре), за которым следует двухбуквенный код страны, поддерживаются почти все страны с доступом в Интернет. - - Специальное значение: `"geoip:private"`, включает в себя все частные адреса, например, `127.0.0.1`. - - Функция инверсии (!), `"geoip:!cn"` означает результаты, не входящие в `geoip:cn`. +- Специальное значение: `"geoip:private"`, включает в себя все частные адреса, например, `127.0.0.1`. +- Функция инверсии `!`: `"geoip:!cn"` обозначает результаты, не входящие в `geoip:cn`. Несколько условий с отрицанием объединяются логическим **AND**, а положительные условия и совокупность всех отрицательных условий — логическим **OR**. Например, `ip: ["geoip:!cn", "geoip:!us", "geoip:telegram"]` соответствует IP, которые не относятся к США **И** не относятся к Китаю, **ИЛИ** являются IP Telegram. - Загрузка IP-адресов из файла: имеет вид `"ext:файл:тег"`, должно начинаться с `ext:` (в нижнем регистре), за которым следует имя файла и тег, файл хранится в [каталоге ресурсов](./features/env.md#путь-к-файлу-ресурсов), формат файла такой же, как у `geoip.dat`, тег должен существовать в файле. > `port`: number | string diff --git a/docs/ru/config/transport.md b/docs/ru/config/transport.md index 243d22f1..d5685df2 100644 --- a/docs/ru/config/transport.md +++ b/docs/ru/config/transport.md @@ -710,18 +710,14 @@ Reality лишь модифицирует TLS, и для реализации н > "UseIP" | "UseIPv6v4" | "UseIPv6" | "UseIPv4v6" | "UseIPv4" > "ForceIP" | "ForceIPv6v4" | "ForceIPv6" | "ForceIPv4v6" | "ForceIPv4" -В предыдущих версиях, когда Xray пытался установить системное соединение с использованием доменного имени, разрешение доменного имени выполнялось системой и не контролировалось Xray. Это приводило к таким проблемам, как [невозможность разрешить доменные имена в нестандартных средах Linux](https://github.com/v2ray/v2ray-core/issues/1909). Для решения этой проблемы в Xray 1.3.1 в Sockopt был добавлен параметр `domainStrategy` в разделе Freedom. - Значение по умолчанию: `"AsIs"`. Если целевой адрес представлен доменным именем, можно настроить соответствующее значение. Поведение Freedom в зависимости от настройки следующее: -- При использовании `"AsIs"` Xray будет напрямую использовать встроенную функцию `Dial` из Go для установления соединения, с фиксированным приоритетом, заданным по умолчанию в RFC6724 (игнорируя такие настройки, как `gai.conf`). _(Простыми словами: IPv6 будет использоваться с приоритетом.)_ +- При использовании `"AsIs"` Xray не выполняет специальную обработку домена. В конечном итоге Xray инициирует соединение, используя встроенный `Dial` из Go. Приоритет выбора адреса фиксирован значениями по умолчанию из RFC6724 (настройки, такие как `gai.conf`, игнорируются). Как правило, приоритет отдается IPv6. - При использовании другого значения будет применен [встроенный DNS-сервер](dns.md) Xray-core для разрешения доменного имени. Если объект `DNSObject` отсутствует, будет использоваться системный DNS. Если существует несколько подходящих IP-адресов, ядро выберет один из них случайным образом. -- `"IPv4"` означает попытку установить соединение, используя только IPv4, - `"IPv4v6"` означает попытку соединения с использованием IPv4 или IPv6, но для доменов с двойным стеком будет использоваться IPv4. - _(Если поменять местами v4 и v6, логика остается аналогичной)_ +- `"IPv4"` означает попытку подключения только через IPv4, `"IPv4v6"` означает попытку подключения через IPv4 или IPv6, но для доменов dual-stack предпочтение отдается IPv4. (При перестановке v4 и v6 местами логика аналогична, поэтому не описывается повторно). - Если во встроенном DNS установлен параметр `"queryStrategy"`, то фактическое поведение будет комбинацией с этим параметром, и будут разрешаться только типы IP-адресов, присутствующие в обоих параметрах. Например: `"queryStrategy": "UseIPv4"` и `"domainStrategy": "UseIP"` фактически эквивалентны `"domainStrategy": "UseIPv4"`. @@ -888,14 +884,18 @@ PS: Если трафик домена, например, обычный веб- Если `type` указан как int, значение должно быть десятичным числом. -> `happyEyeballs`: map +> `happyEyeballs`: [HappyEyeballsObject](#happyeyeballsobject) -Реализация happyEyeballs по RFC-8305 применима только к TCP. Когда целью является доменное имя, она запускает "гонку" между IP-адресами и выбирает первый, с которым удалось установить соединение. Это работает, когда `domainStrategy` установлен на `UseIP`/`ForceIP` (включая их v4/v6/v4v6 версии, но это сокращает список доступных IP-адресов только до v4 или v6, что не рекомендуется). +Реализация Happy Eyeballs (RFC-8305), применима только для TCP. Когда целью является домен, выполняется «гонка» подключений к полученным IP-адресам, и выбирается первый успешный результат. Работает только в том случае, если `Sockopt.domainStrategy` установлен в значение, отличное от `AsIs`. + +Внимание: `UseIPv4v6` / `ForceIPv4v6` сокращают список доступных IP только до IPv4; запрос IPv6 выполняется только в случае сбоя (fallback). Такое использование не рекомендуется. Рекомендуется использовать `UseIP` / `ForceIP` в сочетании с `HappyEyeballs.interleave`. ::: warning При использовании этой функции не используйте `domainStrategy` для исходящего соединения `Freedom`, так как это приведет к тому, что `Sockopt` будет видеть только конечный, уже выбранный IP-адрес. ::: +#### HappyEyeballsObject + ```json "happyEyeballs": { "tryDelayMs": 250, diff --git a/docs/ru/document/level-1/routing-with-dns.md b/docs/ru/document/level-1/routing-with-dns.md index 74f78b7d..8624e6fe 100644 --- a/docs/ru/document/level-1/routing-with-dns.md +++ b/docs/ru/document/level-1/routing-with-dns.md @@ -1,98 +1,151 @@ -# Реализация маршрутизации трафика с помощью модуля DNS +# Реализация точного разделения трафика с помощью DNS -## Обычные методы маршрутизации и их недостатки +## Традиционные методы маршрутизации и их недостатки -Когда Вы пытаетесь вручную настроить правила прокси, у Вас неизбежно возникает вопрос: какой трафик пускать через прокси, а какой - напрямую? +Когда вы пытаетесь вручную создать правила проксирования, неизбежно возникает вопрос: какой трафик пускать через Proxy, а какой — через Direct? -Обычно ответ - черные/белые списки. +Обычный ответ — использование черных и белых списков (Blacklist/Whitelist). -За более чем десять лет сообщество создало огромный список правил, и появилось множество выдающихся проектов: +За более чем десять лет сообщество создало огромные списки правил, и появилось множество отличных проектов: - https://github.com/gfwlist/gfwlist - https://github.com/v2fly/domain-list-community - https://github.com/Loyalsoldier/v2ray-rules-dat -Но они не могут охватить все веб-сайты и не являются на 100% надежными. +Однако они не могут охватить абсолютно все веб-сайты, обладают задержкой в обновлении и не являются на 100% достоверными. -Вот несколько случайных примеров: +Несколько примеров: -- `geosite:cn` — это большая мешанина, куда попадает все, что хоть как-то связано с Китаем. Даже заблокированные домены не всегда своевременно удаляются. - Если вы решите направлять трафик напрямую только потому, что домен находится в этом списке, это не сработает. Например, `ai.ytimg.com` и `login.corp.google.com` заблокированы, но до сих пор не удалены из списка. -- В [README](https://github.com/Loyalsoldier/v2ray-rules-dat) `v2ray-rules-dat` написано, что домены Apple, Microsoft, Google CN одновременно находятся в `geosite:cn` и `geosite:geolocation-!cn`, но на самом деле это не так. (См.: [PR#328](https://github.com/Loyalsoldier/v2ray-rules-dat/pull/328)) -- А что, если домена нет в списке? +- `geosite:cn` — это "сборная солянка": туда добавляют всё, что хоть как-то связано с Китаем. Даже если домен был заблокирован (GFW), его могут не успеть вовремя удалить из списка. + Если вы полагаетесь только на наличие целевого домена в этом списке для направления в Direct, это не сработает. Например, `ai.ytimg.com` или `login.corp.google.com` могут быть заблокированы, но все еще присутствовать в списке. +- В [README](https://github.com/Loyalsoldier/v2ray-rules-dat) репозитория `v2ray-rules-dat` сказано: домены Apple, Microsoft, Google CN одновременно присутствуют и в `geosite:cn`, и в `geosite:geolocation-!cn`, хотя на практике это не так. (См.: [PR#328](https://github.com/Loyalsoldier/v2ray-rules-dat/pull/328)) +- А что, если домена вообще нет в списке? -Это, несомненно, создает проблемы с маршрутизацией. Если ваши правила не обновляются вовремя, вы можете столкнуться с тем, что трафик, который должен идти напрямую, направляется через прокси, а некоторые сайты могут даже не открываться. +Это создает проблемы при маршрутизации. Если ваши правила обновляются несвоевременно, трафик, который должен идти через Direct, может пойти через Proxy, или некоторые сайты вообще перестанут открываться. -Что делать, если неизвестный домен имеет сервер в Китае, и вы хотите подключиться к нему напрямую, но после всех настроек сталкиваетесь с утечкой DNS? +Что делать, если неизвестный домен имеет сервер в Китае, и вы хотите максимально использовать Direct, но после настройки сталкиваетесь с пресловутым [DNS Leak](https://github.com/XTLS/BBS/issues/3#issuecomment-3505661189)? -Так существует ли способ добиться 100% безопасной и точной маршрутизации? +Существует ли способ добиться 99.99% безопасности и точности маршрутизации? -Ответ: Конечно. +Ответ: Безусловно. -## Использование DNS-модуля Xray-core для точной маршрутизации +## Использование DNS-модуля Xray-core для точного разделения трафика -Разумно используя встроенные функции DNS в Xray, такие как fallback, EDNS, фильтрация IP, добавление тегов и т.д., и тщательно настраивая их порядок, вы получите наиболее точные IP-адреса в качестве условия для маршрутизации. +Рационально используя мощные возможности встроенного DNS в Xray (Fallback, ECS, фильтрация по IP, тегирование), и тщательно настраивая порядок серверов, вы получите IP-адрес как условие маршрутизации, который будет гораздо точнее и актуальнее, чем `geosite cn/!cn`. Это связано с тем, что принадлежность IP к региону (GeoIP), особенно к Китаю, меняется довольно редко. -Прежде чем продолжить чтение этой статьи, вам необходимо полностью прочитать и понять «Обзор функции маршрутизации (routing) [Часть 1](./routing-lv1-part1.html) и [Часть 2](./routing-lv1-part2.html)». -В то же время, вы уже, вероятно, до дыр зачитали официальное руководство по настройке, поэтому вы полностью понимаете роль `domainStrategy` в маршрутизации и исходящих соединениях, опции `sniffing` во входящих соединениях, а также поведение, возникающее при различных комбинациях их значений. +Прежде чем продолжить чтение, вам необходимо внимательно изучить и понять: "Основы: Краткий анализ функции маршрутизации (routing) — [Часть 1](./routing-lv1-part1.html), [Часть 2](./routing-lv1-part2.html)". +Предполагается, что вы уже досконально изучили официальное руководство по конфигурации и полностью понимаете работу `domainStrategy` в Routing и Outbound, назначение опций `sniffing` в Inbound, а также поведение системы при различных комбинациях этих параметров. -Все готово? Попробуйте понять следующий отрывок: +Всё готово? Попробуйте осмыслить следующий абзац: -При входящих соединениях `sock` и `http` запрашивается доменное имя. После этого на этапе маршрутизации `domainStrategy`, отличная от `AsIs`, может использовать встроенный DNS для разрешения IP-адреса, который временно используется для сопоставления с правилами маршрутизации. При локальном исходящем соединении `direct`, `domainStrategy`, отличная от `AsIs`, в настройках исходящего соединения может снова использовать встроенный DNS для разрешения IP-адреса для исходящего подключения. Запрос, отправляемый на сервер Xray, содержит только доменное имя, а конкретный IP-адрес для доступа зависит от настроек исходящего соединения `direct` на сервере. +При входящих соединениях `socks` или `http` запрашивается домен. Когда запрос попадает в Routing, стратегия `domainStrategy` (если она отлична от `AsIs`) может использовать встроенный DNS для резолвинга IP, который временно используется для сопоставления правил маршрутизации. При отправке в локальный `direct` Outbound, если его `domainStrategy` не `AsIs`, встроенный DNS снова резолвит IP для исходящего соединения. Запрос, отправляемый на удаленный сервер Xray, содержит только домен; какой именно IP будет использован для доступа, зависит от `direct` Outbound на сервере. -В случае прозрачного прокси ситуация усложняется: `sniffing` для входящих соединений включен, а `destOverride` содержит `[http, tls]`: +В режиме прозрачного прокси (Transparent Proxy) ситуация сложнее. Если включен `sniffing` на Inbound и `destOverride` содержит `[http, tls]`: -- Если `routeOnly = false`, то IP-адрес запроса будет удален, и дальнейший процесс будет таким же, как и для входящего соединения `sock`. -- Если `routeOnly = true`, то будут доступны и домен, и IP-адрес. На этапе маршрутизации можно напрямую сопоставлять правила для доменов и IP, и локальное исходящее соединение `direct` также будет использовать этот IP. Запрос, отправляемый на сервер Xray, содержит только IP-адрес. Как сервер его обработает? Пройдет тот же процесс заново. +- Если `routeOnly = false`, запрошенный IP будет стерт, и дальнейший процесс аналогичен `socks` Inbound. +- Если `routeOnly = true`, то доступны и домен, и IP. В Routing можно напрямую сопоставлять правила по домену и IP, а локальный `direct` Outbound также будет использовать этот IP. Запрос к серверу Xray содержит только IP. Как сервер его обработает? Повторит описанный выше процесс. -Возникли трудности? Вам нужно продолжать перечитывать официальное руководство и пытаться понять его. В противном случае вам будет сложно использовать результаты разрешения DNS-модуля из примеров ниже для правильной маршрутизации. +Возникли трудности? Вам нужно вернуться к официальному руководству и попытаться вникнуть. В противном случае вам будет сложно использовать результаты резолвинга DNS-модуля из примеров ниже для правильной маршрутизации. --- -#### Пример 1: Эта конфигурация разрешает точные, дружественные к CDN IP-адреса, гарантирует отсутствие утечек DNS и, при наличии узлов в Китае, отдает им приоритет при разрешении. Она идеально подходит для сценариев с прозрачным прокси и `realIp`. +#### Пример 1: Конфигурация для получения точного, дружественного к CDN IP-адреса. Гарантирует отсутствие DNS Leak. Если в Китае есть сервер, он будет разрешен приоритетно. Идеально подходит для сценариев RealIP в прозрачном прокси. ```json { "dns": { "servers": [ + // Предотвращение зависания Google CAPTCHA и мониторинга Google China + // (так как многие сторонние сайты могут загружать шрифты Google и т.д.) + { + "address": "1.1.1.1", + "skipFallback": true, + "domains": ["geosite:google", "geosite:google-cn"] + }, + { + "address": "8.8.8.8", + "skipFallback": true, + "domains": ["geosite:google", "geosite:google-cn"], + "finalQuery": true // Завершить цепочку запросов + }, + // Резолвим через Direct домены, которые сообщество считает имеющими узлы в Китае. + // Если результат не соответствует ожидаемому, возможно, домен заблокирован или ушел из Китая. + // Резолвим через Proxy домены, считающиеся китайскими, для Fallback в случае блокировки/ухода. { - // Мы не полностью доверяем geosite:cn, но если домен уже есть в этом списке - // сначала попробуем его разрешить. Если возвращается китайский IP, это значит, что он не заблокирован. В противном случае, он с высокой вероятностью заблокирован, и мы переключаемся на 8.8.8.8 для повторного разрешения, чтобы устранить возможное DNS-загрязнение (это может привести к пустой трате прокси-трафика). - // Причина приоритетного разрешения в том, что это на 100% дружественно к CDN, вы не можете гарантировать, что все авторитетные серверы поддерживают EDNS, и это быстро. "tag": "dns-direct", - "address": "223.5.5.5", - "port": 53, + "address": "114.114.114.114", "skipFallback": true, "domains": ["geosite:cn"], "expectIPs": ["geoip:cn"] }, { - // Аналогично предыдущему - // Мы не полностью доверяем geosite:geolocation-!cn, но если домен уже есть в этом списке - // сначала попробуем разрешить его через прокси. Если возвращается китайский IP, это значит, что у него есть серверы в стране, и мы переключаемся на 8.8.8.8 с clientIp для повторного разрешения, чтобы максимально оптимизировать прямое соединение, поскольку не все авторитетные серверы поддерживают EDNS. + "tag": "dns-direct", + "address": "223.5.5.5", + "skipFallback": true, + "domains": ["geosite:cn"], + "expectIPs": ["geoip:cn"] + }, + { + "address": "1.1.1.1", + "skipFallback": true, + "domains": ["geosite:cn"] + }, + { "address": "8.8.8.8", - "port": 53, + "skipFallback": true, + "domains": ["geosite:cn"], + "finalQuery": true // Завершить цепочку запросов + }, + // Резолвим через Proxy домены, которые сообщество считает НЕ китайскими. + // Если результат не соответствует ожидаемому, пытаемся оптимизировать Direct. + { + "address": "1.1.1.1", "skipFallback": true, "domains": ["geosite:geolocation-!cn"], "expectIPs": ["geoip:!cn"] }, { - // Если домен не находится ни в geosite:geolocation-!cn, ни в geosite:cn, или если разрешение по предыдущим правилам не удалось, будет использоваться этот сервер. - // Причина, по которой неизвестные домены по умолчанию разрешаются через прокси — предотвращение утечки информации о ваших намерениях внутри страны. Это и есть та самая спорная часть, известная как утечка DNS. - // Здесь используется EDNS для попытки получения записей A/AAAA для Китая. - // Если их нет, последовательно запрашиваются следующие DNS-серверы по умолчанию для получения записей, оптимизированных для CDN прокси-узла. "address": "8.8.8.8", - "port": 53, - "clientIp": "222.85.85.85", // Укажите IP-адрес вашего местного интернет-провайдера для получения оптимизированных для прямого подключения записей A/AAAA. Например, если вы используете Henan Telecom, вы можете использовать DNS Henan Telecom. Это не гарантирует 100% дружественности к китайским CDN, так как не все авторитетные серверы поддерживают EDNS. - "skipFallback": false, + "skipFallback": true, + "domains": ["geosite:geolocation-!cn"], + "expectIPs": ["geoip:!cn"] + }, + { + "address": "8.8.8.8", + "clientIp": "222.85.85.85", // Укажите IP вашего локального ISP для получения оптимизированных A/AAAA записей + // Например, если вы используете Henan Telecom, используйте соответствующий IP. + // Не гарантирует 100% дружелюбность к китайским CDN, так как не все Authoritative DNS поддерживают ECS. + "skipFallback": true, + "domains": ["geosite:geolocation-!cn"] + }, + { + "address": "8.8.4.4", + "clientIp": "222.85.85.85", // См. выше + "skipFallback": true, + "domains": ["geosite:geolocation-!cn"], + "finalQuery": true // Завершить цепочку запросов + // Здесь у вас может возникнуть вопрос: эти 4 правила кажутся избыточными по сравнению с 4 выше? Можно ли сократить? + // На самом деле нет, это сделано для достижения максимальной скорости, а также потому что некоторые Authoritative DNS не поддерживают ECS. + }, + // Неизвестные домены: приоритет Китая. Если результат не соответствует, пытаемся оптимизировать Proxy. + { + "address": "8.8.8.8", + "clientIp": "222.85.85.85", // См. выше "expectIPs": ["geoip:cn"] }, + { + "address": "8.8.4.4", + "clientIp": "222.85.85.85", // См. выше + "expectIPs": ["geoip:cn"] + }, + "1.1.1.1", "8.8.8.8" ], - "tag": "dns-proxy" + "tag": "dns-proxy", + "enableParallelQuery": true // Интеллектуальная параллельность: все параллельно, умная группировка, гонка внутри группы }, "routing": { - "domainStrategy": "Зависит от ваших потребностей", + "domainStrategy": "Зависит от ваших требований", "rules": [ { // Маршрутизация для самих DNS-запросов @@ -104,49 +157,94 @@ "inboundTag": ["dns-proxy"], "outboundTag": "proxy" } - // Ваши персональные правила маршрутизации, используйте domain и/или ip для разделения трафика в соответствии с вашими потребностями... + // Ваши персональные правила маршрутизации + // Для разблокировки стриминга и т.д. используйте domain, для разделения трафика (CN/!CN) всегда используйте ip ] } - // Остальное игнорируется, настраивайте по необходимости... + // Остальное пропущено, настройте по необходимости... } ``` -Вы можете разделять трафик на основе разрешенных IP-адресов в сочетании с доменами или полностью полагаясь на IP. +```mermaid +graph TD + A[Получен DNS-запрос] --> B{Классификация домена}; -В среде с прозрачным прокси и `realIp`, после перехвата DNS, вы даже можете установить `domainStrategy=AsIs` и `routeOnly=true`, чтобы избежать повторных DNS-разрешений на всем пути. + B -->|geosite:google
Домены Google| C["Запрос через Proxy
Зарубежный DNS (1.1.1.1...)"]; + C --> C_OUT[Высокая вероятность зарубежного IP]; + C_OUT --> Z[Конец запроса]; ---- + B -->|geosite:cn
Известные домены CN| D["Запрос через Direct
Китайский DNS (114, AliDNS)"]; + D --> E{Результат - китайский IP?}; + E -->|"Да (Ожидаемо)"| F_OUT[Вернуть китайский IP]; + F_OUT --> Z; + E -->|"Нет (Загрязнен/Ошибка/Уход из КНР)"| G["Fallback: Запрос через Proxy
Зарубежный DNS (1.1.1.1...)"]; + G --> G_OUT[Вернуть корректный зарубежный IP]; + G_OUT --> Z; -#### Пример 2: Эта конфигурация разрешает правильные, но не обязательно дружественные к зарубежным CDN адреса, гарантирует отсутствие утечек DNS и при наличии серверных узлов в Китае отдает им приоритет при разрешении. Подходит для сценариев с прозрачным прокси `fakeIp`, входящими соединениями `sock`, `http` и т.д. + B -->|geosite:geolocation-!cn
Известные зарубежные домены| I["Запрос через Proxy
Зарубежный DNS (1.1.1.1...)"]; + I --> J{Результат - зарубежный IP?}; + J -->|"Да (Ожидаемо)"| K_OUT[Вернуть зарубежный IP]; + K_OUT --> Z; + J -->|"Нет (Неожиданный китайский IP/Ошибка)"| L["Fallback: Запрос через Proxy+ECS
Зарубежный DNS (8.8.8.8...)"]; + L --> L_OUT[Вернуть оптимизированный китайский IP]; + L_OUT --> Z; + + B -->|Неизвестный домен| N["Запрос через Proxy+ECS
Зарубежный DNS (8.8.8.8...)
Ожидание китайского IP"]; + N --> O{Результат - китайский IP?}; + O -->|"Да (Есть сервер в Китае)"| P_OUT[Вернуть китайский IP]; + P_OUT --> Z; + O -->|"Нет (Чисто зарубежный сайт)"| Q["Fallback: Запрос через Proxy
Зарубежный DNS (1.1.1.1...)"]; + Q --> Q_OUT[Вернуть оптимизированный зарубежный IP]; + Q_OUT --> Z; + +``` + +Вы можете использовать IP-адреса, полученные с помощью этой конфигурации, в сочетании с доменами или полагаться исключительно на IP для разделения трафика. + +В среде прозрачного прокси RealIP вы даже можете обеспечить полный перехват DNS по всем каналам, установив `domainStrategy=AsIs` и `routeOnly=true`, чтобы избежать вторичного DNS-резолвинга. + +> Примечание: Упомянутая "дружественность к CDN" для зарубежного сегмента оптимизирована под местоположение вашего прокси-сервера. Если вы используете режим "только черный список через прокси" (а не весь зарубежный трафик через прокси), вам необходимо самостоятельно скорректировать ECS в правилах. + +#### Пример 2: Конфигурация для получения корректного адреса (не гарантируется оптимизация для зарубежных CDN). Гарантирует отсутствие DNS Leak. Если в Китае есть сервер, он будет разрешен приоритетно. Подходит для FakeIP прозрачного прокси, Socks, HTTP Inbound. ```json { "dns": { "servers": [ + // Предотвращение зависания Google CAPTCHA и мониторинга Google China + // (так как многие сторонние сайты могут загружать шрифты Google и т.д.) { - // Мы не полностью доверяем geosite:cn, но если домен уже есть в этом списке - // сначала попробуем его разрешить. Если возвращается китайский IP, это значит, что он не заблокирован. В противном случае, он с высокой вероятностью заблокирован, и мы переключаемся на 8.8.8.8 для повторного разрешения, чтобы устранить возможное DNS-загрязнение (это может привести к пустой трате прокси-трафика). - // Причина приоритетного разрешения в том, что это требует минимальных затрат, прямое подключение занимает всего несколько десятков миллисекунд. + "address": "1.1.1.1", + "skipFallback": true, + "domains": ["geosite:google", "geosite:google-cn"], + "finalQuery": true // Завершить цепочку запросов + }, + { + // Мы не доверяем geosite:cn полностью, но если домен уже есть в списке, + // пробуем разрешить его приоритетно. Если возвращается китайский IP — он не заблокирован. + // Если нет — высока вероятность блокировки, Fallback на 8.8.8.8 для повторного резолвинга, + // чтобы устранить возможное загрязнение DNS. + // Причина приоритета: цена ошибки минимальна, Direct-запрос занимает всего ~10 мс. "tag": "dns-direct", "address": "223.5.5.5", - "port": 53, "skipFallback": true, "domains": ["geosite:cn"], "expectIPs": ["geoip:cn"] }, { - // Если домен не находится в geosite:cn, или если разрешение по предыдущему правилу не удалось, будет использоваться этот сервер. - // Здесь используется EDNS для попытки получения записей A/AAAA для Китая. + // Если домена нет в geosite:cn или сработал Fallback из правила выше, используется этот сервер. + // Используем ECS для попытки получения A/AAAA записей для Китая. "address": "8.8.8.8", - "port": 53, - "clientIp": "222.85.85.85", // Укажите IP-адрес вашего местного интернет-провайдера для получения оптимизированных для прямого подключения записей A/AAAA. Например, если вы используете Henan Telecom, вы можете использовать DNS Henan Telecom. Это не гарантирует 100% дружественности к китайским CDN, так как не все авторитетные серверы поддерживают EDNS. + "clientIp": "222.85.85.85", // Укажите IP вашего локального ISP для получения оптимизированных A/AAAA записей + // Например, если вы используете Henan Telecom, используйте соответствующий IP. + // Не гарантирует 100% дружелюбность к китайским CDN, так как не все Authoritative DNS поддерживают ECS. "skipFallback": false } ], "tag": "dns-proxy" }, "routing": { - "domainStrategy": "Должно быть не AsIs, конкретное значение зависит от ваших потребностей", + "domainStrategy": "Обязательно НЕ AsIs, конкретное значение зависит от требований", "rules": [ { // Маршрутизация для самих DNS-запросов @@ -158,32 +256,34 @@ "inboundTag": ["dns-proxy"], "outboundTag": "proxy" } - // Ваши персональные правила маршрутизации, используйте domain и/или ip для разделения трафика в соответствии с вашими потребностями... + // Ваши персональные правила маршрутизации + // Для разблокировки стриминга и т.д. используйте domain, для разделения трафика (CN/!CN) всегда используйте ip ] } - // Остальное игнорируется, настраивайте по необходимости... + // Остальное пропущено, настройте по необходимости... } ``` -В этом сценарии, поскольку все запросы, отправляемые на сервер Xray, являются доменными именами, нет необходимости многократно использовать DNS для поиска оптимального результата. Достаточно быстро определить, не загрязнен ли домен, и по возможности разрешить дружественный к китайским CDN IP-адрес. +В этом сценарии, поскольку все запросы к серверу Xray передаются в виде доменов, нет необходимости использовать DNS для многократного поиска оптимального результата. Достаточно быстро определить, не "загрязнен" ли домен, и по возможности получить китайский IP, дружественный к CDN. -В этом примере китайские IP-адреса, разрешенные DNS-модулем, уже на 99% дружественны к китайским CDN, поэтому в исходящем соединении `direct` вы можете установить `domainStrategy` в значение, **отличное от** `AsIs`, чтобы использовать кэш. Если вы стремитесь к 100% дружественности к китайским CDN, вы можете установить его в `AsIs`, чтобы использовать DNS, настроенный в операционной системе, для повторного разрешения, что займет дополнительно от 1 до нескольких сотен миллисекунд. +В этом примере китайский IP, полученный DNS-модулем, уже на 99% оптимизирован для CDN в Китае. Поэтому вы можете установить `domainStrategy` в `direct` Outbound в значение **не** `AsIs`, чтобы использовать кэш, если это необходимо.
+Если вы стремитесь к 100% оптимизации для китайских CDN, можно установить `AsIs`, чтобы использовать системный DNS для повторного резолвинга (дополнительные затраты времени от 1 до сотен мс). Рекомендуется включить "оптимистичное кэширование" (optimistic caching) для дальнейшего снижения задержки. ## Послесловие -Известно, что многие недобросовестные китайские приложения определяют ваш внешний IP-адрес и связывают его с вашей конфиденциальной информацией, такой как GPS-координаты, номер телефона, адрес доставки еды, а затем сливают эти данные в базы социальной инженерии. ~~Большой брат следит за тобой!!!~~ +Известно, что многие недобросовестные локальные приложения (в Китае) сканируют ваш исходящий зарубежный IP и связывают его с вашим GPS-положением, номером телефона, адресом доставки и другой конфиденциальной информацией, сливая эти данные в базы для социальной инженерии (社工库). ~~Большой брат следит за тобой!!!~~ -Некоторые ошибочно полагают, что это происходит из-за разделения трафика и что этого можно избежать, переключившись на режим черного списка (когда только сайты из черного списка идут через прокси). -На самом деле это не так. Во-первых, черные списки очень легко «отравить»: злоумышленники могут намеренно создавать и добавлять в них сайты-приманки для определения вашего зарубежного IP-адреса. +Некоторые ошибочно полагают, что это вызвано разделением трафика, и что переход на режим "черного списка" (только сайты из черного списка идут через прокси) решит проблему. +На самом деле это не так. Во-первых, в "черный список" очень легко внедрить "отравленные" данные: злоумышленники могут намеренно создать сайты-приманки и добавить их туда, чтобы выявить ваш зарубежный IP. -Во-вторых, если любой из сайтов в черном списке размещен на Cloudflare, даже приманка не нужна. Попробуйте зайти на: https://chatgpt.com/cdn-cgi/trace +Во-вторых, если хотя бы один сайт из черного списка размещен на Cloudflare, даже приманка не нужна. Попробуйте посетить: `https://chatgpt.com/cdn-cgi/trace` -Сообразительные пользователи могут подумать: «А что, если я просто воспользуюсь еще одним публичным прокси?» Но для этого вы должны полностью доверять этому прокси — быть уверенным, что он не ведет логи и не продаст вас, и что им интенсивно пользуются многие люди из вашей страны. Когда один и тот же внешний IP-адрес в течение короткого времени связан с тысячами людей, становится невозможно отследить вас по этому IP. А с надоедливыми капчами на таких «грязных» IP можно и смириться. +Сообразительный читатель может подумать: "А что, если я найду публичный прокси и пущу трафик через него?" Это сработает при условии, что вы полностью доверяете этому прокси (отсутствие логов, продажа данных) и он активно используется множеством людей из вашей страны. Когда один зарубежный IP в единицу времени связан с десятками тысяч людей, невозможно вычислить конкретно вас через этот IP. А с назойливыми капчами на "грязных" IP придется смириться. -Разве Warp от «кибер-добряков» из Cloudflare не идеально подходит под все эти критерии? К сожалению, для сайтов, размещенных на CF, Warp не может полностью скрыть ваш IP-адрес; он эффективен только для серверов, не принадлежащих CF. +Cloudflare Warp от "кибер-филантропа" Cloudflare идеально подходит под описание? К сожалению, для сайтов, размещенных на CF, Warp не скрывает ваш IP полностью; он эффективен только для серверов, не принадлежащих CF. -А как насчет Tor? Он не очень подходит для повседневного использования. Его IP-адреса слишком «грязные», а частая смена выходных узлов может привести к блокировке ваших аккаунтов на многих сайтах. +Подойдет ли Tor? Он плохо подходит для повседневного использования: IP слишком "грязные", а выходные узлы часто меняются, что приводит к блокировке ваших аккаунтов на многих сайтах. -Поэтому, если ваш клиент не поддерживает разделение трафика по приложениям (что возможно только на телефонах и компьютерах), любой другой способ обхода блокировок приведет к утечке вашего внешнего IP-адреса. +Поэтому, если ваш клиент не умеет разделять трафик по приложениям (App split tunneling, доступно только на мобильных устройствах), любой метод обхода блокировок приведет к утечке вашего зарубежного IP. -В общем, я хочу сказать, что при обычных способах обхода блокировок утечка внешнего IP-адреса практически неизбежна. Если вам нужна повышенная защита конфиденциальности, используйте такие инструменты, как Tor. Xray-core как инструмент для борьбы с цензурой сосредоточен на противодействии блокировкам, чтобы помочь вам преодолеть файрвол, но его возможности в плане защиты конфиденциальности весьма ограничены. +В заключение хочу сказать: при обычных методах обхода блокировок утечка зарубежного IP практически неизбежна. Если вам требуется высокий уровень конфиденциальности, используйте Tor и подобные инструменты. Xray-core — это инструмент противодействия цензуре, ориентированный на пробивание "стен" (Firewall), а его возможности в области защиты приватности весьма ограничены. \ No newline at end of file