mirror of
https://github.com/XTLS/Xray-docs-next.git
synced 2026-09-26 00:08:03 +03:00
461 lines
37 KiB
Markdown
461 lines
37 KiB
Markdown
# Маршрутизация
|
||
|
||
Модуль маршрутизации может отправлять входящие данные через разные исходящие соединения в соответствии с разными правилами для достижения цели проксирования по требованию.
|
||
|
||
Например, распространенным сценарием использования является разделение внутреннего и внешнего трафика. Xray может использовать внутренние механизмы для определения трафика из разных регионов, а затем отправлять его на разные исходящие прокси.
|
||
|
||
Более подробный анализ функции маршрутизации: [Краткий анализ функции маршрутизации (routing)](../document/level-1/routing-lv1-part1.md).
|
||
|
||
## RoutingObject
|
||
|
||
`RoutingObject` соответствует элементу `routing` в файле конфигурации.
|
||
|
||
```json
|
||
{
|
||
"routing": {
|
||
"domainStrategy": "AsIs",
|
||
"rules": [],
|
||
"balancers": []
|
||
}
|
||
}
|
||
```
|
||
|
||
> `domainStrategy`: "AsIs" | "IPIfNonMatch" | "IPOnDemand"
|
||
|
||
Стратегия разрешения доменных имен. Используются разные стратегии в зависимости от настройки.
|
||
|
||
- `"AsIs"`: никаких дополнительных операций не выполняется, используется доменное имя из целевого адреса или доменное имя, полученное при sniff. Значение по умолчанию.
|
||
- `"IPIfNonMatch"`: после завершения целого раунда сопоставления, если ни одно правило не сработало, доменное имя разрешается в IP-адрес и выполняется повторное сопоставление.
|
||
- `"IPOnDemand"`: перед началом сопоставления доменное имя сразу разрешается в IP-адрес для сопоставления.
|
||
|
||
Фактическое разрешение будет отложено до момента, когда впервые встретится правило на основе IP, чтобы уменьшить задержку. Результат будет содержать одновременно IPv4 и IPv6 (вы можете дополнительно ограничить это через `queryStrategy` во встроенном DNS). Когда доменное имя разрешается в несколько IP-адресов, каждое правило по очереди пробует все IP-адреса; если хотя бы один IP соответствует требованию, правило считается сработавшим.
|
||
|
||
Когда включены sniff + routeOnly, что позволяет системе маршрутизации одновременно видеть IP и доменное имя, в случае указанного выше разрешения система маршрутизации может видеть только IP, полученный из доменного имени, и не может видеть исходный целевой IP, если только разрешение не завершится неудачей.
|
||
|
||
Когда существуют два доменных имени (целевое доменное имя + результат sniff), приоритет результата sniff всегда выше, как при разрешении, так и при сопоставлении доменных имен.
|
||
|
||
Независимо от того, выполняется разрешение или нет, система маршрутизации не влияет на фактический целевой адрес. Целью запроса по-прежнему остается исходная цель.
|
||
|
||
> `rules`: \[[RuleObject](#ruleobject)\]
|
||
|
||
Соответствует массиву, каждый элемент которого является правилом.
|
||
|
||
Для каждого соединения маршрутизация будет выполняться в соответствии с этими правилами сверху вниз. Когда встречается первое действующее правило, это соединение перенаправляется на указанный им `outboundTag` или `balancerTag`.
|
||
|
||
::: tip
|
||
Если ни одно правило не совпадает, трафик по умолчанию отправляется через первый исходящий канал.
|
||
:::
|
||
|
||
> `balancers`: \[ [BalancerObject](#balancerobject) \]
|
||
|
||
Массив, каждый элемент которого является конфигурацией балансировщика нагрузки.
|
||
|
||
Когда правило указывает на балансировщик нагрузки, Xray выбирает исходящий канал через этот балансировщик нагрузки, а затем перенаправляет трафик через него.
|
||
|
||
### RuleObject
|
||
|
||
```json
|
||
{
|
||
"domain": ["baidu.com", "qq.com", "geosite:cn"],
|
||
"ip": ["0.0.0.0/8", "10.0.0.0/8", "fc00::/7", "fe80::/10", "geoip:cn"],
|
||
"port": "53,443,1000-2000",
|
||
"sourcePort": "53,443,1000-2000",
|
||
"localPort": "53,443,1000-2000",
|
||
"network": "tcp",
|
||
"sourceIP": ["10.0.0.1"],
|
||
"localIP": ["192.168.0.25"],
|
||
"user": ["love@xray.com"],
|
||
"vlessRoute": "53,443,1000-2000",
|
||
"inboundTag": ["tag-vmess"],
|
||
"protocol": ["http", "tls", "quic", "bittorrent"],
|
||
"attrs": { ":method": "GET" },
|
||
"process": ["curl"],
|
||
"outboundTag": "direct",
|
||
"balancerTag": "balancer",
|
||
"ruleTag": "rule name",
|
||
"webhook": {
|
||
"url": "https://api.example.com/alert",
|
||
"deduplication": 300
|
||
}
|
||
}
|
||
```
|
||
|
||
::: danger
|
||
Если указано несколько атрибутов, они должны выполняться **одновременно**, чтобы текущее правило вступило в силу.
|
||
:::
|
||
|
||
> `domain`: \[string\]
|
||
|
||
- **Строка**: Аналогично подстроке ниже, но префикс `"keyword:"` в начале можно опустить.
|
||
- **Регулярное выражение**: Начинается с `"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"`.
|
||
- **Полное совпадение**: Начинается с `"full:"`, остальная часть — доменное имя. Правило вступает в силу, когда это имя полностью совпадает с целевым доменом. Например, `"full:xray.com"` соответствует `"xray.com"`, но не `"www.xray.com"`.
|
||
- **Домен без точек**: Начинается с `"dotless:"`, остальная часть — строка, не содержащая `.`. Правило вступает в силу, если домен не содержит `.` и эта строка совпадает с любой частью целевого домена. Например, `"dotless:pc-"` соответствует `"pc-alice"`, `"mypc-alice"`; подходит для доменов NetBIOS во внутренней сети и т. д. Чувствительно к регистру.
|
||
- **Предопределенный список доменов**: Начинается с `"geosite:"`, далее следует имя, например `geosite:google` или `geosite:cn`. Список имен и доменов см. в разделе [Предопределенные списки доменов](#предопределенные-списки-доменов).
|
||
- **Загрузка доменов из файла**: В формате `"ext:file:tag"`. Должно начинаться с `ext:` (в нижнем регистре), далее следует имя файла и тег. Файл должен находиться в [директории ресурсов](./features/env.md). Формат файла совпадает с форматом `geosite.dat`, указанный тег должен присутствовать в файле.
|
||
|
||
::: tip
|
||
`"ext:geoip.dat:cn"` эквивалентно `"geoip:cn"`
|
||
:::
|
||
|
||
> `ip`: \[string\]
|
||
|
||
Массив, каждый элемент которого представляет собой диапазон IP-адресов. Правило вступает в силу, если какой-либо элемент соответствует целевому IP-адресу. Возможны следующие форматы:
|
||
|
||
- 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`.
|
||
- Загрузка IP-адресов из файла: имеет вид `"ext:файл:тег"`, должно начинаться с `ext:` (в нижнем регистре), за которым следует имя файла и тег, файл хранится в [каталоге ресурсов](./features/env.md#путь-к-файлу-ресурсов), формат файла такой же, как у `geoip.dat`, тег должен существовать в файле.
|
||
- Функция инверсии `!`: `"!10.0.0.0/8"` обозначает всё, что не входит в `10.0.0.0/8`, а `"!geoip:cn"` — результаты, не входящие в `geoip:cn`. Несколько условий с отрицанием объединяются логическим **AND**, а положительные условия и совокупность всех отрицательных условий — логическим **OR**. Например, `ip: ["!geoip:cn", "!geoip:us", "geoip:telegram"]` соответствует IP, которые не относятся к США **И** не относятся к Китаю, **ИЛИ** являются IP Telegram.
|
||
|
||
> `port`: number | string
|
||
|
||
Диапазон портов назначения, возможны три формата:
|
||
|
||
- `"a-b"`: a и b являются положительными целыми числами, меньшими 65536. Этот диапазон является замкнутым интервалом, правило вступает в силу, если порт назначения попадает в этот диапазон.
|
||
- `a`: a является положительным целым числом, меньшим 65536. Правило вступает в силу, если порт назначения равен a.
|
||
- Смесь двух вышеуказанных форматов, разделенных запятой ",". Например: `"53,443,1000-2000"`.
|
||
|
||
> `sourcePort`: number | string
|
||
|
||
Порт источника, возможны три формата:
|
||
|
||
- `"a-b"`: a и b являются положительными целыми числами, меньшими 65536. Этот диапазон является замкнутым интервалом, правило вступает в силу, если порт источника попадает в этот диапазон.
|
||
- `a`: a является положительным целым числом, меньшим 65536. Правило вступает в силу, если порт источника равен a.
|
||
- Смесь двух вышеуказанных форматов, разделенных запятой ",". Например: `"53,443,1000-2000"`.
|
||
|
||
> `localPort`：number | string
|
||
|
||
Порт локального `inbound`, формат соответствует `port`/`sourcePort`. Может быть полезно, когда `inbound` прослушивает диапазон портов.
|
||
|
||
> `network`: "tcp" | "udp" | "tcp,udp"
|
||
|
||
Допустимые значения: "tcp", "udp" или "tcp,udp". Правило вступает в силу, если тип соединения соответствует указанному.
|
||
|
||
Поскольку ядро явно поддерживает только два протокола четвёртого уровня — TCP и UDP, то маршрут с условием, включающим только `"network": "tcp,udp"`, может использоваться для **catch-all** маршрутизации всего трафика. Пример использования — поместить такой маршрут в самый конец всех правил маршрутизации для назначения выходного соединения по умолчанию, если не подходит ни одно из других правил (иначе ядро по умолчанию использует первый outbound).
|
||
|
||
Конечно, другие варианты, явно подходящие для маршрутизации любого трафика, такие как указание диапазона портов **1-65535**, также имеют аналогичное действие.
|
||
|
||
> `sourceIP`: \[string\]
|
||
|
||
Массив, каждый элемент которого представляет собой диапазон IP-адресов. Возможные форматы: IP-адрес, CIDR, GeoIP и загрузка IP-адресов из файла. Правило вступает в силу, если какой-либо элемент соответствует IP-адресу источника.
|
||
|
||
Псевдоним: `source`
|
||
|
||
> `localIP`: \[string\]
|
||
|
||
Формат такой же, как и у других IP. Используется для указания IP-адреса, используемого локальным `inbound` (при прослушивании всех IP-адресов с помощью `0.0.0.0` разные фактические входящие IP будут приводить к разным `localIP`).
|
||
|
||
Не работает для `UDP` (отслеживание невозможно из-за его дейтаграммной природы), всегда будет виден IP-адрес, на котором ведется прослушивание (`listen`).
|
||
|
||
> `user`: \[string\]
|
||
|
||
Массив, каждый элемент которого является адресом электронной почты. Правило вступает в силу, если какой-либо элемент соответствует пользователю-источнику.
|
||
|
||
Аналогично доменному имени, также поддерживается сопоставление с помощью регулярных выражений, начинающихся с `regexp:`. (Также необходимо заменить `\` на `\\`, см. объяснение в разделе `domain`)
|
||
|
||
> `vlessRoute`: number | string
|
||
|
||
Входящее подключение VLESS позволяет клиенту изменять седьмой и восьмой байты UUID на любые значения и использовать их в качестве данных `vlessRoute`. Это дает пользователю возможность настраивать часть серверной маршрутизации по своему усмотрению, не изменяя никаких внешних полей.
|
||
|
||
```
|
||
--------------↓↓↓↓------------------
|
||
xxxxxxxx-xxxx-0000-xxxx-xxxxxxxxxxxx
|
||
```
|
||
|
||
В конфигурации используются данные, закодированные в `big-endian` как `uint16` (если вы не понимаете, что это значит, просто рассматривайте эти четыре символа как шестнадцатеричное число и преобразуйте его в десятичное). Например, `0001→1`, `000e→14`, `38b2→14514`. Причина такого подхода в том, что синтаксис здесь аналогичен `port`, что позволяет гибко указывать множество диапазонов для маршрутизации, так же как и для портов.
|
||
|
||
> `inboundTag`: \[string\]
|
||
|
||
Массив, каждый элемент которого является тегом. Правило вступает в силу, если какой-либо элемент соответствует тегу входящего протокола.
|
||
|
||
> `protocol`: \[ "http" | "tls" | "quic" | "bittorrent" \]
|
||
|
||
Массив, каждый элемент которого представляет собой протокол. Правило вступает в силу, если какой-либо протокол соответствует типу протокола текущего соединения.
|
||
`http` поддерживает только 1.0 и 1.1, h2 пока не поддерживается. (Трафик h2 в открытом виде также встречается очень редко)
|
||
`tls` TLS 1.0 ~ 1.3
|
||
`quic` из-за сложности этого протокола, перехват может иногда не срабатывать.
|
||
`bittorrent` только самый базовый перехват, может не сработать для многих шифрований и обфускаций.
|
||
|
||
::: tip
|
||
Необходимо включить опцию `sniffing` во входящем прокси, чтобы определить тип протокола, используемого соединением.
|
||
:::
|
||
|
||
> `attrs`: object
|
||
|
||
JSON-объект, где ключи и значения являются строками. Используется для проверки значений атрибутов HTTP-трафика (по очевидным причинам, поддерживаются только 1.0 и 1.1). Правило срабатывает, если HTTP-заголовки содержат все указанные ключи, и значения содержат указанную подстроку. Ключи не чувствительны к регистру. Значения поддерживают использование регулярных выражений.
|
||
|
||
Также поддерживаются псевдозаголовки h2, такие как `:method` и `:path`, для сопоставления метода и пути (хотя в HTTP/1.1 эти заголовки отсутствуют)
|
||
|
||
Для метода, отличного от CONNECT, входящего HTTP-запроса, `attrs` можно получить напрямую, для других входящих запросов необходимо включить `sniffing`, чтобы получить эти значения для сопоставления.
|
||
|
||
Примеры:
|
||
|
||
- Проверка HTTP GET: `{":method": "GET"}`
|
||
- Проверка HTTP Path: `{":path": "/test"}`
|
||
- Проверка Content Type: `{"accept": "text/html"}`
|
||
|
||
> `process`: \[string\]
|
||
|
||
Если соединение поступает с локальной машины, выполняется сопоставление по процессу. Если соединение не с локальной машины, сопоставление сразу считается неуспешным. Поддерживаются только Windows и Linux.
|
||
|
||
В частности, на Android клиентское приложение должно вызвать `github.com/xtls/xray-core/common/net.RegisterAndroidProcessFinder()`, чтобы внедрить искатель, предоставляемый Android API. Этот хук позволяет настраивать строку, возвращаемую ядру, что дает возможность реализовать, например, сопоставление по приложениям.
|
||
|
||
Эта опция представляет собой массив, где каждый элемент имеет три режима сопоставления:
|
||
|
||
1. Не содержит слешей: сопоставление по имени процесса.
|
||
2. Содержит слеш, но не заканчивается слешем: сопоставление по абсолютному пути.
|
||
3. Содержит слеш и заканчивается слешем: сопоставляется папка; все процессы в этой папке считаются совпавшими.
|
||
|
||
Примечание:
|
||
|
||
- Все опции чувствительны к регистру.
|
||
- В Windows для обозначения путей используется обратный слеш `\`, но здесь унифицировано требование использовать прямой слеш `/`, например: `C:/Windows/System32/curl.exe`. Это связано с тем, что обратный слеш в JSON воспринимается как символ экранирования, что неудобно (если только вы не решите писать обратные слеши дважды — в таком случае они тоже будут распознаны корректно).
|
||
- При сопоставлении по имени процесса ядро автоматически удаляет суффикс `.exe`, поэтому `["curl"]` сработает для curl как в Linux, так и в Windows. Однако при использовании абсолютного пути суффикс `.exe` опускать нельзя.
|
||
|
||
Специальный синтаксический сахар:
|
||
|
||
- `self/` используется для сопоставления с текущим процессом ядра, что очень полезно для предотвращения петель маршрутизации (routing loops).
|
||
- `xray/` будет заменено на абсолютный путь, где находится текущее ядро; это обеспечит совпадение со всеми процессами Xray, запущенными из этого бинарного файла.
|
||
|
||
> `outboundTag`: string
|
||
|
||
Соответствует тегу исходящего канала.
|
||
|
||
> `balancerTag`: string
|
||
|
||
Соответствует тегу балансировщика нагрузки.
|
||
|
||
::: tip
|
||
Необходимо указать либо `balancerTag`, либо `outboundTag`. Если указаны оба, используется `outboundTag`.
|
||
:::
|
||
|
||
> `ruleTag`: string
|
||
|
||
Необязательно, не имеет фактического эффекта, используется только для идентификации имени этого правила.
|
||
|
||
Если установлено, при совпадении с этим правилом в журнал с уровнем Info будет выводиться соответствующая информация, используемая для отладки того, какое правило маршрутизации сработало.
|
||
|
||
> `webhook`: [WebhookObject](#webhookobject)
|
||
|
||
Необязательно. Если установлено, при попадении в правило будет отправлен POST-запрос на указанный URL.
|
||
|
||
Пример данных, отправляемых в POST-запросе:
|
||
|
||
```json
|
||
{
|
||
"email": "2", // string | null
|
||
"level": null, // number | null
|
||
"protocol": "tls", // string | null
|
||
"network": "tcp", // string
|
||
"source": "tcp:127.0.0.1:54203", // string | null
|
||
"destination": "tcp:dns.google:443", // string
|
||
"routeTarget": null, // string | null
|
||
"originalTarget": "tcp:8.8.8.8:443", // string | null
|
||
"inboundTag": "VLESS_TCP", // string | null
|
||
"inboundName": "vless", // string | null
|
||
"inboundLocal": "tcp:192.168.108.1:443", // string | null
|
||
"outboundTag": "notify-bittorrent", // string | null
|
||
"ts": 1771886901 // number
|
||
}
|
||
```
|
||
|
||
#### WebhookObject
|
||
|
||
```json
|
||
{
|
||
"url": "http://127.0.0.1:8080/api/webhook",
|
||
"deduplication": 10,
|
||
"headers": {
|
||
"X-API-Key": "your-secret-key"
|
||
}
|
||
}
|
||
```
|
||
|
||
> `url`: string
|
||
|
||
URL, по которому будет отправлено уведомление. Поддерживаются как стандартные веб-адреса, так и локальные пути Unix socket.
|
||
|
||
- `https://api.example.com/alert` — стандартный URL для передачи уведомлений по HTTP(S). Используется при интеграции с внешними веб-сервисами или API.
|
||
- `/var/run/webhook.sock` — отправка уведомления через Unix socket, POST-запрос осуществляется на корневой путь `/` данного сокета.
|
||
- `/var/run/webhook.sock:/alert` — отправка уведомления через Unix socket на специфический endpoint `/alert`. Это позволяет интегрироваться с локальными сервисами напрямую, без использования сетевого интерфейса.
|
||
- `@abstract:/webhook` — abstract-сокет (lock-free, только Linux/Android).
|
||
- `@@padded:/webhook` — abstract-сокет с padding.
|
||
|
||
> `deduplication`: number
|
||
|
||
Время (в секундах) для дедупликации событий. При срабатывании нескольких событий в этот период дублирующие запросы игнорируются.
|
||
|
||
> `headers`: object
|
||
|
||
Заголовки HTTP-запроса.
|
||
|
||
### BalancerObject
|
||
|
||
Конфигурация балансировщика нагрузки. Когда балансировщик нагрузки активен, он выбирает наиболее подходящий исходящий канал из указанных исходящих каналов в соответствии с конфигурацией и перенаправляет трафик через него.
|
||
|
||
Часть функций требует данных от одного из двух наблюдательных модулей — [observatory](./observatory.md#observatoryobject) или [burstObservatory](./observatory.md#burstobservatoryobject); см. конкретные описания.
|
||
|
||
```json
|
||
{
|
||
"tag": "balancer",
|
||
"selector": [],
|
||
"fallbackTag": "outbound",
|
||
"strategy": {}
|
||
}
|
||
```
|
||
|
||
> `tag`: string
|
||
|
||
Тег этого балансировщика нагрузки, используется для сопоставления с `balancerTag` в `RuleObject`.
|
||
|
||
> `selector`: \[ string \]
|
||
|
||
Массив строк, каждая из которых будет использоваться для сопоставления с префиксом тега исходящего канала. Например, для следующих тегов исходящих каналов: `[ "a", "ab", "c", "ba" ]`, `"selector": ["a"]` будет соответствовать `[ "a", "ab" ]`.
|
||
|
||
Обычно, когда находится несколько исходящих подключений (outbound), они используются для равномерного распределения нагрузки.
|
||
|
||
> `fallbackTag`: string
|
||
|
||
Если на основе результатов наблюдения за подключениями все исходящие (outbound) оказываются недоступными, то используется исходящее подключение, указанное в этой настройке.
|
||
|
||
> `strategy`: [StrategyObject](#strategyobject)
|
||
|
||
#### StrategyObject
|
||
|
||
```json
|
||
{
|
||
"type": "roundRobin",
|
||
"settings": {}
|
||
}
|
||
```
|
||
|
||
> `type` : "random" | "roundRobin" | "leastPing" | "leastLoad"
|
||
|
||
- `random`: значение по умолчанию. Случайным образом выбирает соответствующий исходящий прокси.
|
||
- `roundRobin`: выбирает соответствующие исходящие прокси по очереди.
|
||
|
||
Две описанные выше стратегии могут опционально использовать наблюдательный модуль. Если задан `fallbackTag` и наблюдательный модуль присутствует, исходящие, отмеченные как недоступные, будут автоматически исключены (узлы без данных наблюдения считаются доступными).
|
||
|
||
- `leastPing` Выбирает исходящий прокси с наименьшей задержкой на основе результатов наблюдения за подключениями.
|
||
- `leastLoad` Выбирает наиболее стабильный исходящий прокси на основе результатов наблюдения за подключениями.
|
||
|
||
Две описанные выше стратегии должны использоваться вместе с наблюдательным модулем; узлы, не покрытые наблюдением, будут напрямую исключены. Если все недоступны и `fallbackTag` не задан, будет выбран исходящий по умолчанию.
|
||
|
||
> `settings`: [StrategySettingsObject](#strategysettingsobject)
|
||
|
||
##### StrategySettingsObject
|
||
|
||
Это необязательный параметр конфигурации, формат которого различается для разных стратегий балансировки нагрузки. В настоящее время этот параметр конфигурации можно добавить только для стратегии балансировки нагрузки `leastLoad`.
|
||
|
||
```json
|
||
{
|
||
"expected": 2,
|
||
"maxRTT": "1s",
|
||
"tolerance": 0.01,
|
||
"baselines": ["1s"],
|
||
"costs": [
|
||
{
|
||
"regexp": false,
|
||
"match": "tag",
|
||
"value": 0.5
|
||
}
|
||
]
|
||
}
|
||
```
|
||
|
||
> `expected`: number
|
||
|
||
Количество оптимальных узлов, выбираемых балансировщиком нагрузки. Трафик будет случайным образом распределен между этими узлами.
|
||
|
||
> `maxRTT`: string
|
||
|
||
Максимально допустимое время RTT (задержки) при измерении скорости.
|
||
|
||
> `tolerance`: float number
|
||
|
||
Максимально допустимая доля неудачных измерений скорости, например, 0.01 означает, что допустим 1% неудачных измерений.
|
||
|
||
> `baselines`: \[ string \]
|
||
|
||
Максимально допустимое стандартное отклонение времени RTT при измерении скорости.
|
||
|
||
> `costs`: \[ CostObject \]
|
||
|
||
Необязательный параметр конфигурации, массив, позволяющий задать веса для всех исходящих соединений.
|
||
|
||
> `regexp`: true | false
|
||
|
||
Использовать ли регулярные выражения для выбора `Tag` исходящего соединения.
|
||
|
||
> `match`: string
|
||
|
||
Сопоставление `Tag` исходящего соединения.
|
||
|
||
> `value`: float number
|
||
|
||
Значение веса. Чем больше значение, тем менее вероятно, что соответствующий узел будет выбран.
|
||
|
||
### Примеры конфигурации балансировки нагрузки
|
||
|
||
```json
|
||
{
|
||
"routing": {
|
||
"rules": [
|
||
{
|
||
"inboundTag": ["in"],
|
||
"balancerTag": "round"
|
||
}
|
||
],
|
||
"balancers": [
|
||
{
|
||
"selector": ["out"],
|
||
"strategy": {
|
||
"type": "roundRobin"
|
||
},
|
||
"tag": "round"
|
||
}
|
||
]
|
||
},
|
||
|
||
"inbounds": [
|
||
{
|
||
"tag": "in"
|
||
}
|
||
],
|
||
|
||
"outbounds": [
|
||
{
|
||
"tag": "out1"
|
||
},
|
||
{
|
||
"tag": "out2"
|
||
}
|
||
]
|
||
}
|
||
```
|
||
|
||
### Предопределенные списки доменов
|
||
|
||
Этот список встроен в каждый установочный пакет Xray, имя файла - `geosite.dat`. Этот файл содержит некоторые распространенные доменные имена. Формат использования: `geosite:xxx`, например, `geosite:google` означает фильтрацию маршрутизации или DNS для доменных имен, соответствующих `google` в файле.
|
||
|
||
Распространенные доменные имена:
|
||
|
||
- `category-ads`: содержит распространенные доменные имена рекламы.
|
||
- `category-ads-all`: содержит распространенные доменные имена рекламы, а также доменные имена поставщиков рекламы.
|
||
- `cn`: эквивалентно объединению `geolocation-cn` и `tld-cn`.
|
||
- `apple`: содержит большинство доменных имен Apple.
|
||
- `google`: содержит большинство доменных имен Google.
|
||
- `microsoft`: содержит большинство доменных имен Microsoft.
|
||
- `facebook`: содержит большинство доменных имен Facebook.
|
||
- `twitter`: содержит большинство доменных имен Twitter.
|
||
- `telegram`: содержит большинство доменных имен Telegram.
|
||
- `geolocation-cn`: содержит распространенные доменные имена сайтов материкового Китая.
|
||
- `geolocation-!cn`: содержит распространенные доменные имена сайтов, не относящихся к материковому Китаю.
|
||
- `tld-cn`: содержит домены верхнего уровня, управляемые CNNIC для использования в материковом Китае, например, доменные имена, оканчивающиеся на `.cn`, `.中国`.
|
||
- `tld-!cn`: содержит домены верхнего уровня, не используемые в материковом Китае, например, доменные имена, оканчивающиеся на `.tw` (Тайвань), `.jp` (Япония), `.sg` (Сингапур), `.us` (США), `.ca` (Канада) и т.д.
|
||
|
||
Вы также можете просмотреть полный список доменов здесь: [Domain list community](https://github.com/v2fly/domain-list-community).
|