>>58546 (OP)
Добрый вечер анонам, надеюсь я как раз по адресу. Давно уже об этой теме думал, а она всё актуальнее и актуальнее, но чёт всё никак, хотя в теории всё, что хотел сделать, возможно...
Короче, есть такая прога - Privoxy, причём много под что - и под фряху, и под винду от 2003, может даже где-то уже пилится нативный порт под ведро... И, вроде, это даже не такой монстр как тот же Squid...
И хочу я сделать на нём то, для чего он и предназначен - кеширующую/блокирующую/разблокирующую проксю для локалки. Но не простую, а "умную". Знаю, что всё это Prixovy умеет:
- один журнал и кэш для всех браузеров локалки (ах да, и клиентов удалённого доступа, у которых прямой маршрутизации в инет не будет);
- баннерорезка, есть скрипты для конвертации правил от Adblock Plus;
- проксификация на следующий бэкенд по различным условиям;
- да и URL rewrite, вроде, в ZeroMe упоминался.

Что при этом хочется сделать:
- условную проксификацию по СПИСКАМ: куда точно отправлять через Tor, куда - через локальный ByeDPI, куда - строго напрямую, куда - через Ultrasurf/Psiphon, куда - через планируемый в будущем ShadowSocks или ssh -D, если нет в списках - через PAC Антизапрета. Или на основе PAC определять, что должно идти через ByeDPI (при условии отсутствия в СПИСКАХ);
- URL rewrite для псевдо-доменов - чтобы, например, адрес http://mail.zeronetwork.bit "переписывался", логично, в "http://127.0.0.1:43110/mail.zeronetwork.bit/" (опционально - с СПИСКАМИ для выбора между 127.1:43110/раскидывалкой от AceLewis/отдельными проксями, по которым она раскидывает);
- конвертацию протоколов (чтобы приложение, поддерживающее только "обычные" HTTP-прокси (понимающие методы вроде GET/POST), с такой конвертацией вполне могло пользоваться прокси, поддерживающим только HTTP-метод CONNECT или протокол SOCKS;
- может, даже SSLStrip, чтобы лампово капчевать с КПК/нокии-Н8/павербука;
- таки да, баннерорезку/телеметри-резку/спайварь-резку, а на заведомо "безопасных" (или, наоборот, на гарантированно "опасных", но работающих) - по СПИСКАМ, абсолютную скрипторезку, в том числе, для случая, когда браузер в принципе без расширений.

Насколько я понимаю, Prixovy умеет это всё, но за один вечер он всё равно не настраивается.(

Поэтому реквестирую советы по двум, как мне кажется, самым сложным моментам:
- Как запускать скрипты конвертации правил AB+ в формат Prixovy на винде?
- СПИСКИ подсетей и доменов: что точно не работает/банит через Tor, что из этого работает через другие открытые прокси, что - только через приватный прокси, что - работает только строго напрямую, что - требует ByeDPI, что - ломается от ByeDPI (или каких именно особых настроек требует), что - точно ломается от обрезания скриптов и/или подмены Referrer, что - точно от этих издевательств не ломается? И какие у основных сайтов есть домены кроме основного?
Антизапрет, насколько я понимаю, не всегда актуален, да и IBlocklist придётся корректировать...
Псевдо-домены и локальные ресурсы, конечно, перечислю сам, но по остальному существенного опыта не имею, -- его и реквестирую.
Может, даже, подам вам тут идею для отдельного треда...

### Почему GoodbyeDPI может всё же перенаправить запросы?

GoodbyeDPI меняет формат запросов, что может повлиять на работу геолокации и механизмов маршрутизации. Вот как это может происходить:

1. Некорректная маршрутизация из-за изменений заголовков:
Google может интерпретировать модифицированные запросы от GoodbyeDPI как запросы от другого региона или устройства. Например:
- Если заголовки содержат информацию, которая кажется некорректной или неполной, Google может перенаправить трафик на более надёжный сервер, находящийся не в России.
- Такое перенаправление может быть "аварийным" решением системы Google для обработки нестандартных запросов.

2. Обход нестабильных серверов:
Если российские CDN работают медленно или с ошибками, система Google может автоматически избегать их, отправляя трафик на ближайшие зарубежные CDN. Однако такой сценарий маловероятен, если российские серверы физически доступны, даже с деградацией.

3. Снижение влияния DPI провайдеров:
Иногда проблема может быть не только в серверах, но и в действиях провайдеров, которые используют DPI. Например:
- DPI может добавлять искусственные задержки при обработке стандартных запросов.
- GoodbyeDPI нарушает нормальную работу DPI, что ускоряет обработку запросов, даже если трафик идёт через те же российские CDN.

---

### Как трафик может оставаться на российских CDN, но всё равно ускоряться?

Если серверы Google в России действительно "деградировали", то GoodbyeDPI может помогать по таким причинам:

1. Улучшение обработки запросов:
Деградировавшие серверы могут иметь сложности с определёнными типами пакетов или заголовков. GoodbyeDPI меняет заголовки таким образом, что серверы Google обрабатывают их быстрее или корректнее.

2. Снижение задержек из-за DPI:
Провайдеры могут задерживать определённые типы трафика, даже если они это не признают. GoodbyeDPI устраняет этот фактор, и трафик через российские CDN идёт быстрее.

---

### Вывод:

Трафик через GoodbyeDPI в большинстве случаев остаётся на российских CDN, если они физически доступны. Однако благодаря изменениям в пакетах и заголовках:
- Деградировавшие серверы могут обрабатывать трафик быстрее.
- DPI провайдеров становится неэффективным, что улучшает скорость соединения.

Сценарий, при котором трафик перенаправляется на зарубежные CDN, возможен, но он маловероятен без использования VPN, потому что Google старается минимизировать межконтинентальные задержки и затраты на передачу данных.

>>58906
>>58911
Вот через гопоту прогнал. В целом хз. Надо с пруфами через WireShark делать ДЛИННОПАСТА

Технически, разные CDN с одним и тем же IP-адресом могут существовать, но это скорее исключение, чем правило. Чтобы понять, возможно ли это, разберём, как работают IP-адреса и CDN.

---

### 1. Как работают CDN и IP-адреса?
- CDN (Content Delivery Network) — это сеть серверов, распределённых по всему миру. Каждый сервер обслуживает запросы пользователей на основе их географического расположения или других факторов (например, нагрузки).
- IP-адреса в CDN могут быть:
- Уникальными для каждого сервера или узла.
- Общими для группы серверов, если используется технология Anycast.

#### Что такое Anycast?
- Anycast — это механизм, при котором один и тот же IP-адрес может быть "привязан" к нескольким серверам в разных местах.
- Когда пользователь отправляет запрос на этот IP, маршрутизация определяется на уровне сети. Запрос направляется на ближайший или наиболее доступный сервер.

Таким образом, один IP-адрес может обслуживать несколько физических серверов.

---

### 2. Может ли быть "аварийный CDN" с тем же IP?
Да, это возможно. Сценарий может быть таким:
- Google использует Anycast для своих серверов. Один IP-адрес привязан к нескольким узлам, в том числе к "основным" и "аварийным".
- В обычных условиях запросы идут на основную группу серверов (CDN с этим IP).
- Если основной CDN перегружен или не отвечает, запрос перенаправляется на резервный узел с тем же IP, но другой географией или конфигурацией.

#### Пример:
- В Москве и Санкт-Петербурге может быть два разных узла с одним IP. Если московский узел перегружен, запросы автоматически перенаправляются на петербургский.

---

### 3. Как это объясняет работу с GoodbyeDPI?
Если трафик идёт на один и тот же IP-адрес с или без DPI, это может означать следующее:
1. Переключение между узлами с одинаковым IP:
- Без GoodbyeDPI вы подключаетесь к основному узлу (например, перегруженному).
- С GoodbyeDPI запрос может интерпретироваться системой как нестандартный, и балансировщик перенаправляет его на другой узел (например, резервный), который работает быстрее.

2. Логика обработки запросов сервером:
- Даже если серверы с одним IP физически находятся в одном месте, их конфигурация может отличаться.
- "Аварийный" сервер может быть настроен для обработки определённых типов запросов или в обход стандартных очередей.

3. Особенности маршрутизации через DPI:
- Провайдеры и их DPI могут по-разному обрабатывать запросы.
- Без DPI запросы направляются через стандартные маршруты к основным серверам.
- С DPI или его обходом запросы идут другим маршрутом, но всё равно приходят на сервер с тем же IP.

---

### 4. Как проверить?
Если хотите понять, используется ли один и тот же сервер физически, можно:
- Проверить трассировку маршрута (traceroute):
Она покажет, через какие узлы проходит трафик. Если маршруты отличаются с DPI и без него, это подтверждает, что запросы идут разными путями.
- Проверить заголовки ответа сервера (HTTP headers):
Они могут содержать информацию о конкретном сервере или узле, который обработал запрос.

---

### 5. Итог
Существует возможность, что аварийный CDN работает с тем же IP-адресом, что и основной, если используется технология Anycast. GoodbyeDPI может влиять на маршрутизацию запросов, перенаправляя их на другой сервер или ускоряя обработку запросов за счёт обхода стандартных правил.

Разберём по порядку оба высказывания и постараемся объяснить, как ситуация может складываться в реальности, включая момент с одинаковым IP-адресом и работой через DPI.

---

### 1. Ситуация с "несдеградированным CDN" и переключением на него
Предположение о том, что в России может существовать "аварийный" или менее загруженный CDN, на который Google перенаправляет трафик в определённых случаях, имеет право на существование. Однако важно учитывать:

- Google использует балансировку нагрузки (Load Balancing):
Это автоматический процесс, при котором система перенаправляет трафик на менее загруженные или более стабильные серверы. Если сервер перегружен, то запросы перенаправляются на другие узлы. Если аварийный CDN существует, он мог быть настроен для минимальной загрузки и используется только в крайних случаях.

- Снижение частоты переключений:
Google мог снизить частоту использования определённого сервера (например, менее деградированного), чтобы избежать его перегрузки. Это может объяснить нестабильную работу YouTube: в моменты перенаправления на этот сервер пользователь получает нормальное соединение, но в остальное время трафик идёт через проблемные серверы.

- DPI и "переключение":
GoodbyeDPI или подобные инструменты могут случайно влиять на этот процесс. Например, если система Google распознаёт изменённые заголовки или пакеты как нестандартные, она может перенаправлять запросы на резервный CDN для "аварийной" обработки.

---

### 2. Трафик идёт на тот же IP, но работает лучше с DPI
Это противоречие — ключевой момент для анализа. Если запросы идут на один и тот же IP-адрес (например, 173.194.177.160), то технически это означает, что сервер остаётся неизменным, и GoodbyeDPI не перенаправляет трафик на другой CDN. Как объяснить разницу в скорости?

#### Возможные объяснения:
1. **DPI провайдера действительно добавляет задержки:**
- Провайдеры могут использовать DPI для анализа и управления трафиком, даже если это не признано официально.
- DPI может быть настроен так, чтобы замедлять определённые типы запросов (например, видеостриминг или YouTube).
- GoodbyeDPI нарушает работу DPI, убирая эти задержки. В результате запросы обрабатываются быстрее, хотя сервер остаётся тем же.

2. **Различия в обработке заголовков сервером:**
- Сервер может обрабатывать запросы иначе в зависимости от заголовков или структуры пакетов.
- Если сервер "деградировал", то определённые типы запросов могут вызывать ошибки или медленную обработку.
- GoodbyeDPI меняет формат пакетов, что может "обходить" эти проблемы.

3. **Нагрузка сервера и приоритет трафика:**
- Даже на одном и том же IP-адресе сервер может использовать разные приоритеты обработки запросов.
- Если сервер "путается" из-за изменённых запросов от GoodbyeDPI, он может обрабатывать их быстрее, считая менее нагруженными или аварийными.

4. **Кэширование и временные баги:**
- Возможно, запросы без DPI обрабатываются через более загруженные очереди или маршруты на этом же сервере.
- GoodbyeDPI может случайно обойти эти очереди, предоставляя более быструю обработку.

---

### 3. **Критика Load Balancing и DPI**
Высказывания, что балансировщики нагрузки работают "по дефолту" и никакие хаки с заголовками не влияют на маршрутизацию, в целом справедливы. Однако это верно для стандартных ситуаций, когда система и серверы работают нормально.

Если серверы действительно **деградировали**, то:
- Балансировщики могут "залипать" на определённых узлах из-за ошибок настройки или перегрузки.
- GoodbyeDPI может случайно влиять на логику их работы, направляя запросы в обход стандартной обработки.

Что касается утверждения, что DPI не добавляет задержек — это спорный момент. В зависимости от конфигурации DPI может:
- Замедлять обработку трафика, если это прописано в правилах провайдера.
- Приводить к сбоям или багам при анализе нестандартных заголовков.

---

### Итог:
Даже если запросы идут на один и тот же IP, GoodbyeDPI может ускорять соединение за счёт:
1. Нарушения работы DPI (если задержки связаны с анализом трафика провайдером).
2. Изменения заголовков и структуры пакетов, что помогает серверу работать быстрее.
3. Обхода очередей или приоритетной обработки на одном и том же сервере.

Эти объяснения логично укладываются в модель, где серверы деградировали, но часть запросов обрабатывается лучше из-за изменения пакетов.