Files
2026-06-02 00:33:44 +08:00

9.5 KiB

Мониторинг подключений

Компонент мониторинга подключений использует HTTP-пинги для проверки состояния подключения исходящих прокси. Результаты мониторинга могут использоваться другими компонентами, например, балансировщиком нагрузки. В настоящее время доступны два режима: observatory (фоновый мониторинг подключений) и burstObservatory (мониторинг параллельных подключений). Выберите один из них в соответствии с вашими потребностями.

ObservatoryObject

ObservatoryObject соответствует элементу observatory в файле конфигурации.

{
  "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 в файле конфигурации.

{
  "burstObservatory": {
    "subjectSelector": ["outbound"],
    "pingConfig": {}
  }
}

subjectSelector: [ string ]

Массив строк, каждый элемент которого будет использоваться для сопоставления с префиксом тега исходящего подключения. Например, для следующих тегов исходящих подключений: [ "a", "ab", "c", "ba" ], "subjectSelector": ["a"] будет соответствовать [ "a", "ab" ].

pingConfig: PingConfigObject

PingConfigObject

{
  // Для каждого исходящего прокси выполняется 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 цикл проверки. :::