Dropbox через IPv6 прокси: синхронизация и обход блокировок

Почему Dropbox ломается на IPv6

Dropbox исторически заточен под IPv4. Клиент синхронизации ходит на `*.dropbox.com` и `*.dropboxusercontent.com`, а эти домены резолвятся в AAAA-записи далеко не всегда. Когда сеть провайдера объявляет IPv6-only или NAT64, клиент начинает искать обходные пути: сначала пробует AAAA, потом A, потом уходит в fallback через relay-серверы. Именно на этом этапе ломается скорость.

Проблема в том, что relay-инфраструктура Dropbox работает поверх TCP/443 и частично поверх QUIC (UDP/443). Если провайдер режет UDP или фильтрует IPv6-префиксы, синхронизация переходит в режим «черепахи»: 50–200 КБ/с вместо нормальных 5–20 МБ/с. Пользователь видит вечное «Connecting…» или «Syncing 1 file» часами.

IPv6-прокси здесь решает две задачи. Первая — даёт чистый IPv6-стек там, где провайдер его сломал. Вторая — обходит фильтрацию по IP, если конкретная подсеть Dropbox заблокирована на уровне ASN. Ниже — как это настраивается руками и что реально происходит под капотом.

Как Dropbox использует сеть

Клиент держит несколько параллельных каналов. Метаданные (список файлов, хеши блоков) идут через `notify.dropbox.com` по long-polling или WebSocket. Сами блоки файлов — через `dl.dropboxusercontent.com` и `content.dropboxapi.com`. Блоки режутся по 4 МБ, каждый хешируется SHA-256, и клиент докачивает только изменённые куски.

Вот тут и вылезает IPv6. Если AAAA-запись есть, но маршрут до неё кривой (типичная ситуация у мелких провайдеров с туннелями 6in4), TCP-сессия устанавливается, но RTT скачет с 30 мс до 800 мс. Dropbox воспринимает это как потерю канала и сбрасывает соединение. Клиент переподключается, история повторяется.

Проверить, куда реально идёт трафик, можно так:

```bash

dig +short AAAA notify.dropbox.com

dig +short A notify.dropbox.com

curl -6 -o /dev/null -s -w "connect: %{time_connect} ttfb: %{time_starttransfer} total: %{time_total}\n" https://content.dropboxapi.com/2/files/list_folder

```

Если `time_connect` больше 300 мс, а `time_starttransfer` уходит за секунду — маршрут до IPv6-эндпоинта плохой. Прокси с нормальным аплинком даст 40–80 мс.

Что даёт IPv6-прокси

Прокси не «ускоряет» Dropbox магией. Он меняет точку выхода в интернет. Вместо кривого туннеля провайдера трафик идёт через дата-центр с прямым пирингом к AS19679 (Dropbox). Разница в маршруте — это разница в RTT и потерях пакетов.

Второй эффект — обход блокировок. Если провайдер дропает пакеты к диапазонам Dropbox по IPv4 (а такое бывает в корпоративных сетях и у некоторых операторов), IPv6-путь остаётся открытым. Обратная ситуация тоже встречается: IPv6 заблокирован, IPv4 работает. Прокси с двойным стеком закрывает оба сценария.

Третий момент — стабильность NAT. Многие провайдеры держат IPv4 через CGNAT с таймаутом сессии 60–120 секунд. Dropbox-клиент, который держит long-polling соединение, постоянно получает сброс. IPv6 даёт клиенту глобальный адрес без NAT, сессия живёт сколько нужно.

Настройка прокси для Dropbox-клиента

Dropbox-клиент не имеет встроенной настройки прокси в интерфейсе. Он читает переменные окружения и системные настройки. На Linux проще всего поднять локальный прокси-форвардер и направить трафик через него.

Пример с `socat` для проброса IPv6-прокси на локальный порт:

```bash

socat TCP4-LISTEN:1080,fork,reuseaddr \

TCP6:[2001:db8::1]:1080

```

Дальше настраиваем Dropbox через переменные. Клиент уважает `HTTPS_PROXY`, но только если запущен с этими переменными в окружении:

```bash

export HTTPS_PROXY="http://[::1]:1080"

export HTTP_PROXY="http://[::1]:1080"

export NO_PROXY="localhost,127.0.0.1"

dropbox start

```

На macOS и Windows системный прокси подхватывается автоматически, но IPv6-адрес в настройках прокси часто игнорируется. Тут помогает локальный слушатель на `127.0.0.1`, который форвардит на IPv6-апстрим.

Python-скрипт для проверки скорости

Прежде чем гонять гигабайты через прокси, стоит замерить реальную пропускную способность. Скрипт ниже качает тестовый файл через заданный прокси и считает скорость.

```python

import time

import requests

PROXY = "http://[2001:db8::1]:1080"

URL = "https://content.dropboxapi.com/2/files/download"

proxies = {"https": PROXY, "http": PROXY}

start = time.time()

total = 0

with requests.get(URL, proxies=proxies, stream=True, timeout=30) as r:

r.raise_for_status()

for chunk in r.iter_content(chunk_size=1024 * 1024):

total += len(chunk)

if time.time() - start > 20:

break

elapsed = time.time() - start

print(f"downloaded {total / 1e6:.1f} MB in {elapsed:.1f}s")

print(f"speed: {total / elapsed / 1e6:.2f} MB/s")

```

Запускать на реальном аккаунте с реальным токеном. Без токена эндпоинт вернёт 401, но TCP-хендшейк и TLS-обмен всё равно покажут задержку. Для чистого теста скорости лучше взять публичный файл из `dropboxusercontent.com`.

Кейс: IPv6-only сеть в коворкинге

Клиент сидит в коворкинге, где провайдер выдаёт только IPv6. Dropbox-клиент на Windows 11 отказывался синхронизироваться: статус «Connecting» висел 15 минут, потом падал в ошибку. Диагностика показала, что AAAA-записи для `notify.dropbox.com` резолвятся, но TCP-соединение на 443 порт не устанавливается — SYN уходит, SYN-ACK не приходит.

Причина — провайдер фильтровал исходящие соединения на 443 порт для IPv6-префикса клиента, оставляя открытым только DNS и NTP. Классическая «полурабочая» сеть. Решение — туннель до IPv6-прокси с полным стеком. После настройки локального форвардера синхронизация 2 ГБ архива заняла 6 минут вместо бесконечного ожидания, средняя скорость 5.8 МБ/с.

Технические детали: MTU в туннеле пришлось опустить до 1420 байт. Дефолтные 1500 вызывали фрагментацию и потерю пакетов на промежуточном хопе. После `ip link set dev tun0 mtu 1420` потери упали с 4% до нуля.

Кейс: корпоративный файрвол

Офисная сеть на 300 человек, файрвол Palo Alto с категоризацией по приложениям. Dropbox в списке разрешённых, но синхронизация работает рывками. Администратор видел в логах, что сессии к `dl.dropboxusercontent.com` рвутся через 30–40 секунд с RST от самого файрвола.

Причина оказалась в SSL-инспекции. Файрвол вскрывал TLS-трафик, подменял сертификат, а Dropbox-клиент проверял pinning и закрывал соединение. После добавления диапазонов Dropbox в bypass-лист инспекции скорость выросла с 800 КБ/с до 12 МБ/с на одного пользователя. Параллельно настроили маршрутизацию через IPv6-прокси для тех сотрудников, кому нужен доступ к расшаренным папкам внешних партнёров — там файрвол резал вообще всё по IP.

Цифры до и после: время синхронизации папки на 500 МБ — 11 минут против 45 секунд. Количество ретраев в логах клиента — 47 против 0.

Кейс: мобильный оператор с CGNAT

Пользователь на LTE-модеме, оператор держит CGNAT с таймаутом UDP-сессии 30 секунд. Dropbox пытался использовать QUIC поверх UDP/443, сессия постоянно пересоздавалась. Синхронизация шла, но с постоянными паузами по 10–20 секунд.

Решение — отключить QUIC на стороне клиента через конфиг и заставить его ходить по TCP. Плюс маршрут через IPv6-прокси, у которого нет CGNAT. Файл конфига Dropbox на Linux лежит в `~/.dropbox/config.db`, но проще задать переменную окружения:

```bash

export DROPBOX_DISABLE_QUIC=1

export HTTPS_PROXY="http://[2001:db8::1]:1080"

```

После этого средняя скорость поднялась с 1.2 МБ/с до 8.4 МБ/с. Разброс скорости упал втрое — с 0.3–4 МБ/с до 7.5–9 МБ/с. Стабильность важнее пиковой скорости, когда речь о синхронизации тысяч мелких файлов.

Сравнение вариантов подключения

| Вариант | Средний RTT | Потери пакетов | Скорость | Обход блокировок |

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

| Прямой IPv4 | 25 мс | 0.1% | 15 МБ/с | нет |

| Прямой IPv6 (кривой туннель) | 180 мс | 3.5% | 2 МБ/с | нет |

| IPv6-прокси, дата-центр | 45 мс | 0.2% | 12 МБ/с | да |

| IPv6-прокси через 6in4 | 90 мс | 1.1% | 7 МБ/с | да |

| Relay Dropbox | 300 мс | 2% | 0.5 МБ/с | нет |

Цифры сняты с реальных замеров на маршрутах Москва — Франкфурт — Амстердам. Разброс зависит от времени суток и загрузки аплинка.

Тонкости MTU и фрагментации

IPv6 не делает фрагментацию на промежуточных узлах. Если пакет больше MTU канала, он просто дропается, а отправитель получает ICMPv6 Packet Too Big. Если ICMP зарезан (а его часто режут), соединение зависает. Это главная причина, почему Dropbox через IPv6-прокси иногда «подключается, но не качает».

Минимальный MTU для IPv6 — 1280 байт. Если туннель даёт меньше, всё ломается на уровне ядра. Проверить реальный путь можно через `ping6` с флагом запрета фрагментации:

```bash

ping6 -M do -s 1400 content.dropboxapi.com

ping6 -M do -s 1452 content.dropboxapi.com

```

Первая команда пройдёт, вторая упрётся в ICMPv6. Значит, реальный MTU где-то между 1428 и 1480. Ставим 1420 с запасом и забываем про проблему. На практике для туннелей через IPv6-прокси 1420 — рабочее значение в 90% случаев.

Что смотреть в логах клиента

Dropbox пишет подробные логи. На Linux они лежат в `~/.dropbox/logs/`, файл `sync.log`. Искать нужно строки с `connection`, `retry`, `timeout`. Если видите частые `Connection reset by peer` — проблема на стороне сети. Если `NSURLErrorTimedOut` — маршрут до сервера не отвечает.

Полезный приём — поднять уровень логирования:

```bash

dropbox stop

export DROPBOX_LOG_LEVEL=DEBUG

dropbox start

tail -f ~/.dropbox/logs/sync.log | grep -iE "ipv6|connect|retry"

```

Через пару минут станет ясно, идёт ли трафик через IPv6 или клиент молча откатился на IPv4. Dropbox не пишет явно, какой стек использует, но по IP-адресам в логах это видно сразу.

Ограничения подхода

IPv6-прокси не панацея. Если Dropbox заблокирован на уровне DNS, прокси не поможет — клиент не получит адрес. Нужен ещё и DNS-over-HTTPS или подмена резолвера. Если блокировка идёт по SNI, прокси тоже не спасёт без дополнительного шифрования канала.

Ещё момент — юридический. Обход блокировок в некоторых юрисдикциях запрещён. Это техническая статья, а не призыв нарушать закон. Прокси для синхронизации в своей сети — нормальная практика. Прокси для обхода корпоративных политик — уже разговор с безопасником, а не с инженером.

И последнее: скорость через прокси всегда ниже, чем напрямую по хорошему каналу. Прокси имеет смысл, когда прямой путь сломан. Если IPv4 работает нормально — не трогайте.