Files
XTLS_Xray-docs-next/docs/ru/config/observatory.md
T
2026-06-02 00:33:44 +08:00

126 lines
9.5 KiB
Markdown

# Мониторинг подключений
Компонент мониторинга подключений использует HTTP-пинги для проверки состояния подключения исходящих прокси. Результаты мониторинга могут использоваться другими компонентами, например, балансировщиком нагрузки.
В настоящее время доступны два режима: [observatory](#observatoryobject) (фоновый мониторинг подключений) и [burstObservatory](#burstobservatoryobject) (мониторинг параллельных подключений).
Выберите один из них в соответствии с вашими потребностями.
## ObservatoryObject
`ObservatoryObject` соответствует элементу `observatory` в файле конфигурации.
```json
{
"observatory": {
"subjectSelector": ["outbound"],
"probeUrl": "https://www.google.com/generate_204",
"probeInterval": "10s",
"enableConcurrency": false
}
}
```
> `subjectSelector`: \[ string \]
Массив строк, каждый элемент которого будет использоваться для сопоставления с префиксом тега исходящего подключения.
Например, для следующих тегов исходящих подключений: `[ "a", "ab", "c", "ba" ]`, `"subjectSelector": ["a"]` будет соответствовать `[ "a", "ab" ]`.
> `probeUrl`: string
URL-адрес, используемый для проверки состояния подключения исходящего прокси.
> `probeInterval`: string
Интервал между проверками.
Формат времени: число + единица измерения, например `"10s"`, `"2h45m"`.
Поддерживаемые единицы измерения: `ns`, `us`, `ms`, `s`, `m`, `h` (наносекунды, микросекунды, миллисекунды, секунды, минуты, часы).
Обратите внимание, что поскольку интервал между запросами фиксирован, периодические запросы через равные промежутки времени могут создавать характерный шаблон поведения. Использование протоколов с мультиплексированием или включение `mux` может смягчить эту проблему.
> `enableConcurrency`: true | false
- `true` - проверять все соответствующие исходящие прокси одновременно, после чего сделать паузу на время, указанное в `probeInterval`.
- `false` - проверять соответствующие исходящие прокси по очереди, делая паузу на время, указанное в `probeInterval`, после проверки каждого прокси.
## BurstObservatoryObject
`BurstObservatoryObject` соответствует элементу `burstObservatory` в файле конфигурации.
```json
{
"burstObservatory": {
"subjectSelector": ["outbound"],
"pingConfig": {}
}
}
```
> `subjectSelector`: \[ string \]
Массив строк, каждый элемент которого будет использоваться для сопоставления с префиксом тега исходящего подключения.
Например, для следующих тегов исходящих подключений: `[ "a", "ab", "c", "ba" ]`, `"subjectSelector": ["a"]` будет соответствовать `[ "a", "ab" ]`.
> `pingConfig`: [PingConfigObject](#pingconfigobject)
### PingConfigObject
```json
{
// Для каждого исходящего прокси выполняется 10 проверок в течение 10 минут, конкретное время проверок случайно
// Если все они завершатся неудачей, узел будет помечен как неисправный в течение 10 ~ 20 минут
// После сбоя достаточно одной успешной проверки, чтобы узел был помечен как исправный, на это потребуется не более 10 минут
"destination": "https://connectivitycheck.gstatic.com/generate_204",
"connectivity": "",
"interval": "1m",
"sampling": 10,
"timeout": "5s",
"httpMethod": "HEAD"
}
```
> `destination`: string
URL-адрес, используемый для проверки состояния подключения исходящего прокси.
Этот URL-адрес должен возвращать код состояния HTTP 204.
По умолчанию `"https://connectivitycheck.gstatic.com/generate_204"`.
> `connectivity`: string
URL-адрес, используемый для проверки подключения к локальной сети.
Этот URL-адрес должен возвращать код состояния HTTP 204.
Пустая строка означает, что проверка подключения к локальной сети не выполняется.
Эта проверка выполняется только тогда, когда проверка `destination` завершается неудачей. Это позволяет более четко отразить в журнале причину отсутствия сетевого подключения.
Внимание: в режиме прозрачного проксирования этот запрос может быть перехвачен прозрачным прокси и снова попасть в Xray для маршрутизации (в зависимости от вашей конфигурации). Необходимо принять дополнительные меры, чтобы он не был перехвачен прозрачным прокси, например, обход по IP-адресу URL, либо использование cgroup, pid-маршрутизации и других способов, чтобы запросы Xray полностью не перехватывались. Либо вы можете выбрать URL-адрес, который соответствует правилу прямого подключения, и позволить этому запросу быть перехваченным прозрачным прокси.
> `interval`: string
Ожидаемый **средний** интервал между проверками для каждого исходящего прокси.
Формат времени: число + единица измерения, например `"10s"`, `"2h45m"`.
Поддерживаемые единицы измерения: `ns`, `us`, `ms`, `s`, `m`, `h` (наносекунды, микросекунды, миллисекунды, секунды, минуты, часы).
По умолчанию `"1m"`. Минимальное допустимое значение — `"10s"`. Если указано меньше, будет использовано `"10s"`.
> `sampling`: number
Количество последних результатов проверок, которые нужно сохранить.
По умолчанию `10`.
> `timeout`: string
Время ожидания ответа при проверке.
Формат такой же, как и у `interval`.
По умолчанию `"5s"`.
> `httpMethod`: string
HTTP-метод, используемый для выполнения проверки (например, `"HEAD"`, `"GET"`).
По умолчанию `"HEAD"`.
::: tip
Принцип работы мониторинга параллельных подключений заключается в том, что каждые `interval` \* `sampling` (далее — цикл проверки) для каждого совпавшего исходящего прокси немедленно планируется задача проверки, но сама проверка выполняется в случайный момент времени в пределах цикла каждой задачи. Это означает, что по сравнению с `observatory` (фоновым мониторингом подключений) характерный шаблон этого детектора менее заметен. Но если `interval` задан слишком малым или `sampling` слишком большим, что приводит к частым проверкам, шаблон станет более заметным.
`interval` и `sampling` совместно влияют на чувствительность переключения при сбое и восстановления. Когда узел постоянно не проходит проверки, чтобы пометить его как неисправный, требуется минимум 1 цикл проверки и максимум 2 цикла проверки. Для восстановления после сбоя требуется одна успешная проверка, что зависит от плотности проверок; максимум на это уходит 1 цикл проверки.
:::