Логика работы

Этапы проверки

• Переход по ссылке ВАШ_ДОМЕН/group&query=QUERY, где group - id группы, query - передаваемое значение (необходим, только для remote редиректаб или для статистики)
• Определение группы. Если группа не найдена, юзер отправляется по мусорной ссылке (Trash url в настройках)
• Определение потока. Последовательно сверху вниз идет проверка по каждому потоку.
  • У каждого потока есть свой собственный набор фильтров и тип их проверки. Проверка фильтров идет сверху вниз.
    • && - абсолютно все. Значит все условия фильтров должны подойти, чтобы сработал редирект по потоку.
    • || - любой. При любом первом подходяшем фильтре, сработает редирект по потоку.
  • Если поток подходит, то происходит редирект значению этого потока.
  • В противном случае проверяется следующий поток.
• Если никакой поток не подошел, то редирект происходит по ссылке из группы

Данная схема распределения трафика может показаться сложной, но парочка примеров расставит все на свои места.

Пример №1

Тип редиректа группы: HTTP Redirect

Ссылка: https://google.com

У него 2 потока

Поток №1:

• name: black
• type redirect: HTTP Redirect.
• relation: &&
• url: https://example.com/black
• filters:
  • device - (desktop, ipad)
  • bot ipv6 - true

Поток №2:

• name: white
• type redirect: HTTP Redirect.
• relation: ||
• url: https://example.com/white
• filters:
  • device - (mobile)
  • country - (Canada, France)

Варианты

1. Допустим, по ссылке перешел человек с компьютера, у которого внешний ip является ipv6. Тогда его перенаправит по ссылке на https://example.com/black.

2. Если пользователь перешел по ссылке с айпада и его внешний адрес был ipv4, то его перенаправит на https://google.com.

3. Юзер перешел с мобильного. Его перенаправило на https://example.com/white.

4. Юзер перешел с десктопа из Канады с ipv4. Его перенаправило на https://example.com/white. У второго потока стоит условие || (любой), а у первого потока && (абсолютно все). т.е у первом потока не выполнилось обязательное условие ipv6.

5. Итак далее...