Как проверить прокси на утечку IPv6

Прокси купил, настроил — сидишь довольный. А потом бац — твой реальный IPv6 улетел на сервер. И вся анонимность коту под хвост.

Утечка IPv6 — классическая проблема. Провайдеры давно раздают IPv6, софт по умолчанию его поддерживает, а пользователи про это забывают. Результат: ты думаешь, что сидишь через прокси, а твой домашний адрес торчит наружу.

Разберем, как это проверить на всех трёх системах. И что делать, если утечка уже есть.

Почему IPv6 утекает

Коротко: у тебя есть IPv4 и IPv6. Прокси работает только по IPv4. Приложение видит, что IPv4 ушёл через прокси, и решает: "а дай-ка я IPv6 отправлю напрямую". Потому что IPv6 в системе работает, маршрут есть, а прокси про IPv6 ничего не знает.

В итоге трафик раздваивается. IPv4 — через прокси, IPv6 — напрямую к целевому серверу. Сервер видит оба адреса. Твоя анонимность — ноль.

Проверяется это просто: смотришь, какой адрес видит сервер. Если видит твой реальный IPv6 — утечка.

Инструменты для проверки

Для проверки нужно:

1. Убедиться, что трафик идёт через прокси

2. Посмотреть, какие IP видит внешний сервер

3. Сравнить с реальным IP провайдера

Базовый инструмент — curl. Он умеет работать через прокси и показывать ответы сервера. Плюс несколько онлайн-сервисов, которые отдают твой IP в разных форматах.

Онлайн-сервисы для проверки

| Сервис | Что отдаёт | Формат |

|--------|------------|--------|

| ifconfig.me | IPv4 + IPv6 | Текстовый |

| icanhazip.com | Только IPv4 | Текстовый |

| ipv6.icanhazip.com | Только IPv6 | Текстовый |

| api.ipify.org | IPv4 + IPv6 | JSON |

| checkip.amazonaws.com | Только IPv4 | Текстовый |

Для диагностики бери icanhazip — он минималистичный, без лишнего мусора в ответе.

Проверка на Linux

На Linux проверка делается парой команд. Терминал, curl, никаких GUI.

Сначала узнай свой реальный IPv6:

```bash

curl -6 ifconfig.me

```

Запомни этот адрес. Теперь проверь через прокси:

```bash

curl -x socks5://user:pass@proxy.example.com:1080 -6 ifconfig.me

```

Если прокси HTTP/HTTPS, формат другой:

```bash

curl -x http://user:pass@proxy.example.com:3128 -6 ifconfig.me

```

Ключ `-6` форсирует IPv6. Если прокси не поддерживает IPv6, curl должен вернуть ошибку. Если вернул адрес — смотри, совпадает ли он с реальным.

Совпал? Утечка. Прокси пропустил твой IPv6 напрямую.

Более жёсткая проверка — отправить запрос на IPv6-сервер и посмотреть заголовки:

```bash

curl -x http://proxy.example.com:3128 -6 -v https://ipv6.icanhazip.com/ 2>&1 | grep -E 'Connected to|HTTP'

```

В выводе будет видно, через какой адрес шло соединение.

Пример: nginx за прокси

Ситуация: ты крутишь nginx как прокси для внутренних сервисов. Настроил всё по IPv4, а клиенты приходят с IPv6. Nginx решает: "IPv4 — через прокси, IPv6 — напрямую к бэкенду".

В логах nginx видно:

```

192.168.1.100 - - [10/Jan/2025:12:34:56 +0300] "GET / HTTP/1.1" 200 1234 "-" "curl/7.88"

2001:db8::1 - - [10/Jan/2025:12:34:57 +0300] "GET / HTTP/1.1" 200 1234 "-" "curl/7.88"

```

Первый запрос — через прокси (IPv4). Второй — напрямую (IPv6). Решение: запретить IPv6 в nginx или добавить обработку X-Forwarded-For для IPv6.

Проверка на macOS

macOS — тот же Unix, но с нюансами. curl есть по умолчанию, но сетевые настройки чуть другие.

Проверка через curl работает так же:

```bash

curl -x socks5://user:pass@proxy.example.com:1080 -6 ifconfig.me

```

Но на macOS есть дополнительная проблема: система может сама решать, куда отправлять IPv6-трафик. Даже если прокси настроен в системных настройках, некоторые приложения игнорируют эти настройки.

Проверь системные настройки прокси:

```bash

networksetup -getwebproxy Wi-Fi

networksetup -getsocksfirewallproxy Wi-Fi

```

Если прокси настроен, смотри, не вылезает ли IPv6 наружу. Самый надёжный способ — отключить IPv6 на интерфейсе и проверить, работает ли вообще доступ к IPv6-сайтам:

```bash

sudo ifconfig en0 inet6 -alias

curl -6 ifconfig.me

```

Если после отключения IPv6 на интерфейсе curl всё равно получает ответ — значит, система использует другой интерфейс (например, TUN-устройство от VPN).

Кейс: Safari игнорирует прокси

Пример: на macOS настроен SOCKS5-прокси в системных настройках. Chrome работает через него, Safari — нет. Safari имеет собственную систему прокси, которая иногда не подхватывает системные настройки.

Решение: в Safari → Настройки → Дополнения → Прокси выставить "Использовать системные". Или вручную прописать прокси в настройках Safari.

Проверка: открываешь ipv6.icanhazip.com в браузере. Если видишь свой реальный IPv6 — утечка.

Проверка на Windows

Windows — зоопарк. Тут и системные настройки, и браузерные, и приложения, которые вообще живут своей жизнью.

Проще всего — через PowerShell. Но curl на Windows — это алиас к Invoke-WebRequest, который не умеет работать с прокси напрямую. Поэтому ставь настоящий curl или используй netsh.

Проверка через curl (если установлен):

```powershell

curl.exe -x http://user:pass@proxy.example.com:3128 -6 ifconfig.me

```

Через netsh можно посмотреть, какие маршруты активны:

```powershell

netsh interface ipv6 show route

netsh interface ipv6 show addresses

```

Если видишь несколько маршрутов по умолчанию — это проблема. Система может отправлять IPv6-трафик не через прокси.

Настройка прокси в Windows

Windows имеет глобальные настройки прокси в Параметры → Сеть → Прокси. Но эти настройки работают только для приложений, которые их уважают. Браузеры — уважают. Консольные утилиты — нет.

Для консольных утилит нужно выставлять переменные окружения:

```powershell

\:HTTP_PROXY="http://user:pass@proxy.example.com:3128"

\:HTTPS_PROXY="http://user:pass@proxy.example.com:3128"

\:NO_PROXY="localhost,127.0.0.1"

```

После этого curl будет работать через прокси. Но это не защищает от утечек IPv6 — если приложение решит, что IPv6 быстрее, оно пойдёт напрямую.

Кейс: Edge и системный прокси

Пример: в Windows настроен системный прокси. Edge его подхватывает. Но при заходе на сайт, который раздаётся через CDN с IPv6, Edge решает: "IPv6 — быстрее, пойду напрямую".

В результате: запрос к сайту идёт через прокси по IPv4, но часть ресурсов (картинки, скрипты) загружаются напрямую по IPv6. Сервер видит два разных IP.

Решение: в Edge ввести `edge://flags/#enable-quic` и отключить QUIC. Или в настройках браузера запретить IPv6.

Автоматизация проверки на Python

Когда прокси много, проверять каждый вручную — ад. Напиши скрипт.

```python

import requests

import socket

def check_ipv6_leak(proxy_url):

proxies = {

'http': proxy_url,

'https': proxy_url

}

Проверка через IPv6 сервис

try:

r = requests.get('https://ipv6.icanhazip.com/',

proxies=proxies,

timeout=10)

proxy_ip = r.text.strip()

except:

return "IPv6 не работает через прокси"

Реальный IPv6

real_ip = socket.getaddrinfo('ifconfig.me', 80, socket.AF_INET6)[0][4][0]

if proxy_ip == real_ip:

return f"УТЕЧКА: прокси показал {proxy_ip}"

else:

return f"Чисто: прокси {proxy_ip}, реальный {real_ip}"

print(check_ipv6_leak('http://user:pass@proxy.example.com:3128'))

```

Скрипт сравнивает IP, который вернул прокси, с реальным IP системы. Если совпало — утечка.

Что делать с утечкой

Обнаружил утечку — действуй.

**Вариант 1: Отключить IPv6 на интерфейсе**

На Linux:

```bash

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1

sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1

```

На macOS:

```bash

sudo networksetup -setv6off Wi-Fi

```

На Windows: Параметры → Сеть → Изменить параметры адаптера → ПКМ по адаптеру → Свойства → снять галку с "IPv6".

**Вариант 2: Настроить прокси на работу с IPv6**

Если прокси поддерживает IPv6, используй его. Пример для curl:

```bash

curl -x socks5h://proxy.example.com:1080 -6 ifconfig.me

```

Суффикс `h` в `socks5h` заставляет curl резолвить домены через прокси, а не локально.

**Вариант 3: Использовать VPN с поддержкой IPv6**

Некоторые VPN-сервисы умеют корректно обрабатывать IPv6. Но это отдельная история.

**Вариант 4: Настроить iptables/nftables для блокировки IPv6**

На Linux:

```bash

sudo ip6tables -A OUTPUT -j DROP

```

Жёстко, но надёжно. Весь IPv6-трафик будет заблокирован.

Проверка через lexic.ml

Если используешь IPv6-прокси от lexic.ml, проверка делается так:

```bash

curl -x socks5://user:pass@proxy.lexic.ml:1080 -6 ifconfig.me

```

Прокси поддерживает IPv6, поэтому утечки быть не должно. Но проверь — вдруг настройки сбились.

Дополнительно: проверь, что DNS-запросы тоже идут через прокси. Иногда DNS утекает отдельно от трафика.

```bash

curl -x socks5h://user:pass@proxy.lexic.ml:1080 -6 ifconfig.me

```

Буква `h` — ключевая. Без неё DNS резолвится локально.

Частые грабли

**Грабли 1: Прокси только для HTTP/HTTPS**

SOCKS5-прокси работает на уровне TCP, HTTP-прокси — только для HTTP. Если используешь HTTP-прокси, весь остальной трафик (DNS, UDP) идёт напрямую.

**Грабли 2: Браузерные расширения**

Расширения для управления прокси (FoxyProxy, SwitchyOmega) могут конфликтовать с системными настройками. Проверяй, какое расширение активно.

**Грабли 3: Docker и контейнеры**

В Docker-контейнерах сеть изолирована. Если контейнер использует host-сеть, он наследует настройки хоста. Если bridge — может быть своя конфигурация.

Проверка внутри контейнера:

```bash

docker exec container_name curl -6 ifconfig.me

```

**Грабли 4: Двойной прокси**

Иногда настраивают цепочку: прокси → VPN → ещё прокси. В такой схеме утечка может произойти на любом уровне. Проверяй каждый узел отдельно.

Итог

Проверка на утечку IPv6 — пять минут работы. curl, пара команд, один онлайн-сервис. Если нашёл утечку — отключай IPv6 на интерфейсе или настраивай прокси корректно.

Не делай вид, что проблемы нет. IPv6-утечка — это дыра в анонимности размером с твой реальный IP.