Как это устроено и что мы выяснили
Технические подробности для тех, кому интересно, почему инструкция именно такая. Все наблюдения сделаны на одном живом аккаунте (1,8 ТБ файлов, 152 ГиБ в безлимите, ~30 тыс. фото) 13 октября 2026 года. На вашем аккаунте картина может отличаться.
Почему токен Полигона
rclone подключается к Яндекс Диску через собственное OAuth-приложение. Сейчас с его токеном Яндекс отвечает
200 на запрос сведений о Диске (/v1/disk), но 410 GoneError («Ресурс больше недоступен») на любой
список файлов, скачивание и т. п. С токеном Полигона — отладочного
приложения самого Яндекса для REST API — те же запросы работают.
Backend yandex в rclone требует в токене refresh_token, иначе падает с unable to get RefreshToken.
У токена Полигона его нет, поэтому скрипты кладут заглушку "refresh_token":"unused" и срок действия
в 2099 году: rclone не пытается обновить токен и просто им пользуется. Когда токен истечёт (примерно через год),
rclone начнёт получать 401, нужен новый.
Можно зарегистрировать своё приложение на oauth.yandex.ru только с правами на чтение. Работает ли оно сейчас или Яндекс блокирует его так же, как rclone, мы не проверяли.
REST API против WebDAV
REST (yandex) |
WebDAV | |
|---|---|---|
| Хеши (MD5) | есть, у каждого файла | нет |
| Скорость одного потока | ~0,8 МБ/с | ~0,2 МБ/с |
| Под нагрузкой | медленная выдача ссылок, 500 |
503, обрывы соединений |
Поэтому всё построено на REST. MD5 у Яндекса и у Google Drive позволяет rclone check сверять копию
без скачивания.
Почему тайм-ауты такие
Скачивание через REST — это цепочка: GET /v1/disk/resources/download → ссылка на downloader.disk.yandex.ru
→ редирект на узел хранения sNNN<dc>.storage.yandex.net → данные.
- Около половины файлов (154 из 300 в случайной выборке, два прохода подряд совпали) не отдавались вообще.
Почти все файлы аккаунта вели на узлы
…klg(Калуга), и примерно 55% из них не отвечали. Отсеять мёртвые файлы по имени узла нельзя: на одном узле бывают и живые, и мёртвые. - Выдача ссылки к середине дня деградировала: от 1 до 60 секунд или
500, даже без нашей нагрузки.
По умолчанию rclone ждёт 5 минут и повторяет 10 раз, и потоки надолго встают на мёртвых файлах.
Поэтому: --timeout 60s, --low-level-retries 2, --retries 1. Мёртвый файл отваливается за 1–2 минуты,
живой, но медленный успевает. Список несохранённого — в логе, повторный запуск докачивает.
Безлимит
Фото безлимитной автозагрузки живут в отдельной области photounlim. REST API на photounlim:/ отвечает
DiskAreaDoesNotExistsError, WebDAV на /photounlim/ — 404, в плоском списке файлов (/resources/files)
их нет. Значение photounlim_size в /v1/disk есть, а самих файлов нет.
Веб-версия работает через внутренний API https://disk.yandex.ru/models-v2?m=<метод>
(тело {sk, connection_id, apiMethod, requestParams}, sk — CSRF-токен страницы). Нужные методы нашлись
в сетевом журнале браузера при ручном переносе пары фото:
| Метод | Назначение |
|---|---|
intapi/photo-init-snapshot |
id снимка раздела «Фото» |
intapi/photo-get-snapshot |
кластеры по датам, у каждого счётчик albums.photounlim |
intapi/photo-get-clusters-with-resources |
файлы кластеров, пути вида /photounlim/<имя> |
mpfs/bulk-async-move |
перенос: operations: [{src, dst, force: 0}], не больше 40 за запрос |
mpfs/bulk-operation-status |
статус: WAITING → DONE |
yd.js вызывает их через fetch из открытой вкладки Диска (подключаясь к браузеру по CDP), поэтому
запросы идут с настоящими cookies и TLS-отпечатком браузера. Имена в /photounlim/ уникальны, так что
перенос в одну папку проходит без конфликтов, а force: 0 не даёт ничего перезаписать.
Скорость около 85–120 файлов в минуту: Яндекс выполняет перемещения по очереди.