Я потратил неприлично много поздних вечеров на отладку скриптов, которые должны были всего лишь «забрать файл и идти дальше». В девяти случаях из десяти виноват был cURL — он делал ровно то, что я ему сказал, а не то, что мне действительно было нужно. Оказалось, между «curl -O работает» и «curl -O надёжно работает в продакшене» — целая пропасть.
Именно для этого и написан этот гайд. cURL предустановлен на macOS, большинстве дистрибутивов Linux, а также в Windows 10 и новее, так что с большой вероятностью он уже есть у вас на компьютере. Но между тихо провалившимися редиректами, загадочными 403-ошибками и переходом от «скачать один файл» к «скачать 500 файлов, не положив терминал» легко застрять. Я покажу флаги, которые действительно важны, пошаговые команды, которыми пользуюсь сам, ошибки, на которых чаще всего спотыкаются люди, и момент, когда cURL уже не помогает — и что использовать вместо него.
Что такое cURL и почему он вообще вам нужен?
cURL — это бесплатный инструмент с открытым исходным кодом для работы из командной строки, который передаёт данные на сервер или с сервера по URL. Он поддерживает HTTP, HTTPS, FTP, SFTP и ещё длинный список протоколов, поэтому встречается буквально везде: от bash-скриптов и Dockerfile до CI-пайплайнов. Под капотом команда curl, которую вы вводите в терминале, использует libcurl — библиотеку на C, встроенную во множество приложений и языковых обёрток. Например, расширение cURL в PHP — это один из таких случаев; а популярная библиотека Requests в Python — отдельный HTTP-клиент, построенный на urllib3, а не на libcurl.
На момент написания актуальный стабильный релиз — curl 8.21.0, выпущенный в июне 2026 года, хотя не стоит рассчитывать, что именно эта сборка идёт в комплекте с вашей ОС. Версии curl, поставляемые через дистрибутивы, часто отстают от upstream-проекта на месяцы, а иногда и дольше, поэтому перед использованием флага вроде --parallel лучше проверить curl --version.
Зачем скачивать файлы через cURL? Основные сценарии
Меня часто спрашивают, зачем вообще нужен командный инструмент, если браузер и так прекрасно скачивает файлы. Честный ответ: браузеры хороши, пока вам не нужно что-то автоматизировать.
| Сценарий | Чем хорош cURL |
|---|---|
| Скачивание бинарников в CI/CD-пайплайнах | Можно скриптовать, GUI не нужен |
| Получение ответов API или экспортов данных | Поддерживает заголовки, авторизацию и вывод в пайп |
| Возобновление больших загрузок по SSH | Встроенная поддержка продолжения загрузки (-C -) |
| Автоматизация регулярных загрузок (cron-задачи) | Лёгкий, удобно сочетается с shell-скриптами |
| Скачивание файлов за авторизацией | Гибкие флаги аутентификации (basic, token, cookies, .netrc) |
Загрузка через браузер — это разовое ручное действие. cURL превращает то же самое в повторяемый процесс: его можно запланировать, встроить в цепочку команд, повторить при сбое и запустить одинаково на сотне серверов одновременно. В этом и смысл — не в «крутизне», а в воспроизводимости.
Основные флаги cURL для скачивания файлов
Я постоянно возвращаюсь примерно к дюжине флагов — они закрывают 90% всех задач. Ниже — шпаргалка, которую мне самому хотелось получить много лет назад, сгруппированная по назначению.
Флаги для вывода и сохранения файлов
-O(--remote-name) сохраняет файл под именем, которое соответствует последней части URL. Удобно, но может молча перезаписать уже существующий файл с тем же именем.-o <filename>(--output) позволяет задать точное имя файла самому:curl -o report.pdf https://example.com/downloads/file.pdf.-J(--remote-header-name) берёт имя файла из заголовкаContent-Dispositionна стороне сервера вместо URL. Это удобно для загрузок через API, но относитесь к имени, пришедшему с сервера, как к недоверенному вводу — лучше скачивать в отдельную папку, а не в домашний каталог, как рекомендует сам curl в документации по безопасности.
Обязательные флаги поведения для любой загрузки
-L(--location) заставляет curl следовать за HTTP-редиректами. Без него ответ 3xx сохранится как крошечная HTML-страница перенаправления вместо нужного файла — это самая частая ошибка в стиле «почему моя загрузка сломалась».-C -(--continue-at -) возобновляет прерванную загрузку с того места, где она остановилась.-s/-Sработают тихо, но всё равно показывают ошибки — отлично для скриптов, где не нужен прогресс-бар в логах.--limit-rate 1Mограничивает скорость передачи (полезно на общих каналах или когда не хочется забивать лимитированный интернет).--connect-timeout 10и--max-time 300не дают зависшему соединению повесить ваш скрипт навсегда.--retry 3и--retry-delay 5автоматически повторяют запрос при временных сбоях — по man-странице curl, сочетайте это с--retry-all-errorsтолько если повторять тот же запрос действительно безопасно.
Флаги для прогресса и отладки
-#показывает простой индикатор прогресса вместо стандартной таблицы статистики.-vвыводит подробный лог, включая все заголовки запроса и ответа — мой любимый вариант, когда что-то идёт не так.-I(--head) запрашивает только заголовки ответа — отличный предварительный тест перед большой загрузкой.-wпозволяет вывести после передачи свой форматированный результат, напримерcurl -o /dev/null -s -w "%{http_code}\n" <url>, чтобы просто проверить HTTP-код.
Перед началом
- Сложность: от начального до среднего уровня (разделы про пакетную загрузку и авторизацию чуть сложнее)
- Время: примерно 15–20 минут, чтобы пройтись по основным командам
- Что понадобится: терминал (macOS Terminal, shell в Linux или Windows PowerShell/WSL), установленный curl (проверьте через
curl --version) и тестовый URL — для примера я буду использовать публичный asset из релиза на GitHub, потому что он стабильный и свободно доступен
Как скачивать файлы с cURL: пошагово
Шаг 1: Скачайте один файл
Самая база: curl -O <url> сохраняет файл под его исходным именем, а curl -o myfile.zip <url> позволяет переименовать его на лету.
curl -LO https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
Теперь я по умолчанию всегда добавляю -L — без исключений. Меня слишком много раз подводил редирект, который незаметно превращал мою «загрузку» в HTML-файл на 400 байт. В терминале вы должны увидеть индикатор прогресса, который дойдёт до конца, а затем файл окажется в текущей папке.
Когда команда выполнится успешно, шкала прогресса дойдёт до 100%, и в текущем каталоге появится curl-8.21.0.tar.gz. Перед использованием лучше убедиться, что файл на месте:
ls -lh curl-8.21.0.tar.gz
Шаг 2: Скачайте и переименуйте файл
Используйте -o, когда вам нужно конкретное локальное имя файла, а не то, на которое заканчивается URL:
curl -L -o curl-latest.tar.gz -S https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
Флаг -S здесь снова включает показ ошибок, если где-то выше по скрипту вы также используете -s. Комбинация -L -o <name> -S — это, по сути, моя стандартная команда для одиночной загрузки.
Шаг 3: Возобновите прерванную загрузку
Если большая загрузка оборвалась посередине — плохой Wi‑Fi, сбой VPN, что угодно — не начинайте сначала. Запустите:
curl -C - -LO https://example.com/large-file.iso
Но есть нюанс: это работает только если сервер поддерживает запросы диапазона байтов. Заголовок Accept-Ranges: bytes — хороший признак, но его отсутствие ещё не доказывает, что диапазоны не поддерживаются. Надёжнее всего проверить ответ сервера на реальный range-запрос: для возобновляемой загрузки обычно возвращается 206 Partial Content с корректным Content-Range. Запустите команду возобновления и посмотрите статус через -v или -D -; если сервер игнорирует диапазон или отклоняет смещение, лучше начать загрузку заново, чем полагаться на частичный файл.
Шаг 4: Скачивайте с индикатором прогресса — или без лишнего шума
Для более аккуратного вывода в интерактивном терминале используйте: curl -# -LO <url>. Для скриптов и cron-задач, где нужны только ошибки, а не лишний шум: curl -sS -LO <url>. Я почти везде использую тихий вариант, кроме случаев, когда отлаживаю вручную.
Шаг 5: Ограничьте скорость загрузки
На общем офисном канале или когда не хочется быть тем самым человеком, который съедает всю полосу во время видеозвонка, я ограничиваю скорость так:
curl --limit-rate 1M -LO https://example.com/big-dataset.zip
Единицы измерения — K, M и G для килобайт, мегабайт и гигабайт в секунду соответственно.
Шаг 6: Сохраняйте заголовки ответа вместе с файлом
Иногда мне нужно точно знать, что вернул сервер — тип контента, заголовки кэша и всё такое — без лишнего мусора в терминале:
curl -L -D headers.txt -o file.zip https://example.com/file.zip
В этом случае заголовки ответа попадают в headers.txt, а сам файл — в file.zip. Это удобно для поиска несоответствий в Content-Type или проверки, действительно ли CDN кэширует то, что вы ожидаете.
Советы и частые ошибки
- Совет: Всегда по умолчанию используйте
-L. Я правда не вижу ни одного минуса в этом флаге, а вот часы времени из-за него уже терял. - Совет: В скриптах сочетайте команду загрузки с
--fail, чтобы ответ не из диапазона 2xx реально завершал скрипт ошибкой, а не молча сохранялся как «файл». - Ошибка: Не сочетайте
-C -с--remove-on-error— curl считает эти флаги несовместимыми, потому что для возобновления нужен частично загруженный файл. - Ошибка:
-Oможет перезаписывать файлы без предупреждения. Если вы массово скачиваете файлы в общую папку, используйте--output-dir, чтобы всё было в одном месте и без сюрпризов.
Как скачивать несколько файлов и делать пакетные загрузки с cURL
Примеры с одним файлом — это просто. Настоящие сценарии, которые я строил на практике — например, забор ночных экспортов данных или синхронизация бинарников между билд-серверами — требовали параллелизма, и вот здесь большинство туториалов обычно... заканчиваются. Есть три подхода, которые стоит знать, каждый чуть сложнее предыдущего.
Подход 1: Несколько URL в одной команде cURL
Самый простой вариант — просто перечислить URL:
curl -LO https://example.com/a.zip -LO https://example.com/b.zip -LO https://example.com/c.zip
Это работает, но последовательно — curl полностью завершает загрузку одного файла, прежде чем начать следующий. Для трёх файлов нормально, для трёхсот — мучение.
Подход 2: Параллельные загрузки с --parallel (curl 7.66+)
Начиная с curl 7.66, можно добавить --parallel (или -Z), чтобы загружать несколько URL одновременно:
curl --parallel --parallel-max 5 --remote-name-all \
https://example.com/a.zip https://example.com/b.zip https://example.com/c.zip
Полезно знать: значение --parallel-max по умолчанию — 50, а это куда больше одновременных соединений, чем порадуется большинство серверов и даже ваша собственная сеть. Я предпочитаю указывать --parallel-max явно и консервативно — обычно 4–8 — вместо того чтобы доверять дефолту.
Подход 3: xargs и Bash-циклы для параллелизма из списка URL
Если у меня есть большой список URL в текстовом файле, я обычно беру xargs:
cat urls.txt | xargs -n1 -P 8 curl -O -L
Или, если нужен более точный контроль над каждым заданием, — bash-цикл с запуском в фоне:
while read -r url; do
curl -O -L "$url" &
done < urls.txt
wait
Команда wait в конце важна — без неё скрипт завершится раньше, чем закончатся фоновые загрузки.
Когда вместо cURL стоит использовать wget или aria2
Скажу прямо: cURL подходит не всегда. Если вам нужно зеркалировать целое дерево каталогов сайта, wget -r рекурсивно обходит страницы «из коробки» — cURL для этого просто не предназначен. Если же вам нужны многосегментные загрузки из нескольких источников ради максимальной скорости одного очень большого файла, aria2c действительно быстрее.
| Инструмент | Лучше всего подходит для |
|---|---|
| cURL | Точность, скрипты, загрузка одного файла или небольших пакетов, работа с API |
| wget | Рекурсивная загрузка и зеркалирование сайтов, простое массовое скачивание статических файлов |
| aria2 | Многосегментные и многoисточниковые загрузки, максимум скорости на больших файлах |
Сильная сторона cURL всегда была в точности и композиции — пайпы, скрипты, гибкость протоколов — а не в грубом краулинге.
Как скачивать защищённые файлы с cURL: варианты аутентификации
Большинство туториалов по cURL останавливаются на -u user:pass и считают тему закрытой. Это пережиток более старого интернета. В 2026 году файлы, которые я реально скачиваю, приходят из REST API, панелей сессий и CI-систем — и у каждого из этих источников свой способ авторизации.
Basic Auth
curl -u username:password -O https://legacy-server.example.com/file.zip
Подходит для старых FTP-серверов или простых HTTP-эндпоинтов. Только помните, что пароль попадёт в историю shell и список процессов, если не быть осторожным — для чего-то чувствительного я бы это не использовал.
Авторизация через Bearer / OAuth токен
Это как раз тот случай, который в большинстве гайдов недооценён, хотя я использую его чаще всего:
curl -H "Authorization: Bearer $GITHUB_TOKEN" \
-LO https://api.github.com/repos/curl/curl/releases/assets/12345
Это реальный шаблон для скачивания приватного asset из релиза GitHub — подставьте свой токен и ID ассета. REST API и ресурсы, защищённые OAuth2, сейчас в основном говорят именно на этом языке.
Авторизация через cookie-сессию
Для веб-приложений, где вход создаёт сессию, сохраните cookie jar при логине и используйте его при скачивании:
curl -c cookies.txt -d "user=me&pass=secret" https://example.com/login
curl -b cookies.txt -O https://example.com/protected/file.zip
Файл .netrc для скриптов и CI-среды
Это мой предпочтительный способ для всего, что работает без присмотра. Создайте файл ~/.netrc (или _netrc в Windows):
machine example.com
login myusername
password mypassword
Ограничьте доступ через chmod 600 ~/.netrc, а затем обращайтесь к нему так:
curl --netrc -LO https://example.com/protected-file.zip
Плюс в том, что учётные данные не попадают ни в историю shell, ни в исходники скрипта — это особенно важно в CI/CD, где скрипты часто логируются целиком.
| Способ авторизации | Флаг/опция | Лучше всего для |
|---|---|---|
| Basic auth | -u user:pass | Устаревший FTP, простой HTTP |
| Bearer token | -H "Authorization: Bearer <token>" | REST API, OAuth2 |
| Cookie auth | -b cookies.txt (+ -c для сохранения) | Веб-приложения на сессиях |
Файл .netrc | --netrc или --netrc-file | CI/CD, скриптовая среда |
Устранение типичных сбоев при скачивании через cURL
Это тот раздел, который мне самому очень хотелось бы иметь под рукой в начале пути, потому что почти никто его нормально не раскрывает. Поиск в духе «почему cURL не скачивает файл» — очень частый и очень раздражающий, а исправления обычно сводятся к одной строке, если знать причину.
| Симптом | Вероятная причина | Решение |
|---|---|---|
curl: (60) SSL certificate problem | Самоподписанный или просроченный сертификат | --cacert <file> или -k (только для dev) |
403 Forbidden / пустой файл | Сервер блокирует стандартный User-Agent curl | -A "Mozilla/5.0..." или -H "User-Agent: ..." |
Загрузка начинается заново с 0 при -C - | Сервер не поддерживает Range | Проверьте через curl -I <url> наличие Accept-Ranges: bytes |
| Сохранён файл размером 0 байт | Не был выполнен редирект | Добавьте флаг -L |
curl: (28) Operation timed out | Медленный сервер или проблемы сети | --connect-timeout 10 --max-time 300 + --retry 3 |
| Вместо файла сохранилась HTML-страница | Страница требует рендеринга JavaScript | curl не умеет выполнять JS — см. раздел ниже |
Ошибки SSL-сертификата: что они означают и как их исправить
Ошибка 60 означает, что curl не смог проверить SSL-сертификат сервера — обычно потому, что он самоподписанный, просроченный или выдан центром сертификации, которому curl не доверяет. Если сервером управляете вы, укажите curl нужный CA bundle через --cacert /path/to/ca.pem. Флаг -k (--insecure) полностью отключает проверку, что допустимо в локальной dev-среде, но очень плохая идея для всего, что связано с продакшеном или реальными пользовательскими данными.
403 Forbidden и пустые загрузки
Удивительно много серверов блокируют запросы, которые представляются как curl/8.21.0 — стандартный User-Agent curl — считая их ботами или скрейперами. Обычно решение простое: притвориться браузером:
curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" -LO https://example.com/file.zip
Чтобы перед полной загрузкой проверить, что реально возвращает сервер, я использую: curl -o /dev/null -s -w "%{http_code}\n" <url>.
Таймауты, повторные попытки и нестабильные соединения
Это та команда, которую я бы набил себе на руку, если бы был смелее в вопросе татуировок.
Моя основная команда для загрузки — та, которую я реально использую в production-скриптах, — собирает все флаги надёжности вместе:
curl -L -C - --retry 5 --retry-delay 3 --connect-timeout 10 --max-time 600 --fail -O <url>
То есть: следование редиректам, возобновление, пять повторов с задержкой 3 секунды, таймаут подключения 10 секунд, общий лимит 10 минут и жёсткий фейл при плохом HTTP-статусе — по сути, всё, чему я научился на собственных ошибках.
cURL в реальной автоматизации: CI/CD, пайпы и безопасность скриптов
Передача вывода cURL в другие инструменты
curl вообще не обязан что-то сохранять на диск — передача потока сразу в другую команду — одна из самых недооценённых его возможностей:
curl -sL https://example.com/archive.tar.gz | tar xz
curl -s https://api.example.com/data | jq '.results'
Скачать и сразу распаковать или скачать и сразу распарсить — всё в одной строке. Этот шаблон я постоянно использую для разовых выгрузок данных.
Использование cURL в GitHub Actions и CI/CD
Минимальный шаг GitHub Actions, который скачивает бинарник с логикой повторов и громко падает при ошибке:
- name: Download binary
run: |
curl -L --fail --retry 3 --retry-delay 5 \
-o app-binary "https://example.com/releases/app-binary"
Храните токены как секреты CI и обращайтесь к ним через переменные окружения — никогда не зашивайте их прямо в скрипт. И обязательно используйте --fail (или --fail-with-body, если вам нужен body ошибки для отладки), чтобы сломанная загрузка действительно ломала сборку, а не успешно завершалась мусором.
Вопрос безопасности curl | sh
Этот вопрос всплывает почти на каждом форуме для разработчиков — и не зря: если вы напрямую передаёте вывод curl в sh, вы исполняете удалённый код, который не посмотрели сами, полностью полагаясь на то, что сервер не скомпрометирован и соединение не подменено. В этом и риск — никакой паранойи, просто обычная цепочка поставки.
Безопаснее сначала скачать файл, посмотреть скрипт, проверить checksum или GPG-подпись, если они предоставлены, и только потом запускать:
curl -sL https://example.com/install.sh -o install.sh
cat install.sh # сначала реально прочитайте
sha256sum install.sh # сравните с опубликованным checksum, если он есть
bash install.sh
Известные установщики вроде rustup и Homebrew всё ещё используют шаблон curl | sh, и для них это в целом приемлемо, потому что у этих проектов устоявшаяся команда и понятный канал распространения. Но лично я всё равно предпочту потратить лишние десять секунд на проверку скрипта, чем потом выяснять, что доверял ему зря.
Когда cURL уже недостаточно: страницы с JS-рендерингом, антиботы и структурированные данные
Вот режим отказа, который многих ставит в тупик, и чаще всего это не их вина: вы запускаете curl -O против страницы, которая выглядит обычной, а вместо ожидаемого контента получаете пустую HTML-оболочку, страницу-челлендж от Cloudflare или просто мусор. curl сделал ровно то, для чего создан — забрал сырой HTTP-ответ. Он просто не умеет выполнять JavaScript, проходить CAPTCHA или обходить антибот-системы по отпечатку браузера. Это не баги curl — это вообще не его зона ответственности.
Почему cURL ломается на современных веб-страницах
Современные одностраничные приложения часто отдают почти пустой HTML-каркас, а настоящий контент подгружается и рендерится на клиенте через JavaScript уже после загрузки страницы — а это curl никогда не исполняет. Более того, такие системы, как Cloudflare и Akamai, могут специально отдавать challenge-страницы всему, что не похоже на реальный браузер, а повторяющиеся запросы cURL с одного IP быстро могут попасть под rate limiting или быть помечены как бот-трафик.
Следующий шаг: AI scraping API для разработчиков
Я бы сказал, что cURL — правильный инструмент примерно для 80% всех загрузок файлов и данных: статические ресурсы, ответы API, всё, что отдаётся как обычный HTTP-ресурс. А вот оставшиеся 20% — страницы с тяжёлым JavaScript или защитой от ботов — это как раз тот случай, когда разработчики часами мучаются с заголовками и User-Agent, а потом всё равно переходят на другой уровень.
Именно эту нишу моя команда и закрыла с Thunderbit, вместе с расширением Chrome, по которому нас чаще всего и знают. На стороне разработчика Open API Thunderbit даёт вам POST /distill, который возвращает чистый Markdown, готовый для LLM, прямо из URL — при этом рендеринг страницы берёт на себя сам сервис — а также POST /extract, который возвращает структурированный JSON, совпадающий со схемой, когда вам нужны не просто читаемые тексты, а поля и значения. Есть и MCP-сервер, так что агенты в Claude или Cursor могут вызывать thunderbit_distill и thunderbit_extract прямо в процессе задачи, а также CLI (npx @thunderbit/thunderbit-cli distill <url>), который по ощущениям очень похож на curl в терминале. Например, JSON-вывод можно передать в jq: thunderbit distill <url> --format json | jq -r '.data.markdown'; а вывод --format markdown — отправить в текстовый инструмент или сохранить в файл.
Если сравнивать напрямую, разница очень заметна. Запрос cURL к странице продукта, рендерящейся через JS, может вернуть почти пустой <div id="root"></div>. А эквивалентная команда thunderbit distill возвращает уже отрендеренный контент страницы в виде чистого Markdown. Distill стоит 1 кредит за URL, а Extract — 20 кредитов за URL. Актуальные лимиты по эндпоинтам различаются: Batch Distill поддерживает до 100 URL за задачу, а Batch Extract принимает до 50 URL с одной общей схемой. Перед настройкой production-очереди обязательно проверьте актуальную документацию API.
Если вы только начинаете разбираться в теме, наш материал о том, что такое веб-скрейпинг на практике — неплохая отправная точка, а гайд по скрейпингу без кода объясняет ту же проблему с другой стороны — для тех, кто в вашей команде не собирается открывать терминал. Для более широкого сравнения инструментов в этой области мы также подготовили обзор лучших AI web scrapers.
Краткая шпаргалка: cURL для скачивания файлов
| Задача | Команда |
|---|---|
| Базовая загрузка | curl -LO <url> |
| Свой файл-имя | curl -L -o myfile.zip <url> |
| Возобновить загрузку | curl -C - -LO <url> |
| Тихо, но с ошибками | curl -sSL -O <url> |
| Параллельные загрузки | curl --parallel --parallel-max 5 -O <url1> -O <url2> |
| Аутентификация по Bearer-токену | curl -H "Authorization: Bearer <token>" -LO <url> |
| Надёжная загрузка для скрипта | curl -LO --retry 5 --retry-delay 3 --max-time 600 --fail <url> |
| Передать в инструмент извлечения | curl -sL <url> | tar xz |
Заключение и главные выводы
Скачивание файла через curl начинается очень просто — curl -O, и на этом вроде бы всё — но настоящая ценность скрыта в деталях: когда добавить -L, когда лучше продолжить загрузку, а не начинать заново, какой способ авторизации реально подходит вашему сценарию и что делать, когда вместо нужного файла вы получаете 403 или пустую HTML-оболочку. Я использовал каждый из этих приёмов, обычно сразу после того, как на собственном опыте понял, почему это важно.
curl по-прежнему остаётся моим инструментом по умолчанию для простых загрузок файлов и скриптуемой HTTP-работы — он быстрый, вездесущий и отлично сочетается с остальной shell-цепочкой. Но когда вы упираетесь в страницу с JavaScript-рендерингом или антибот-защиту, проблема уже не в том, чтобы добавить ещё один флаг curl; это знак, что нужен другой уровень, и именно здесь API вроде Thunderbit подхватывает задачу, не заставляя вас выходить из терминала.
Сохраните эту шпаргалку, попробуйте команду с повторными попытками и возобновлением на следующей нестабильной загрузке, а если однажды упёрлись в стену, где curl просто возвращает мусор, вы уже знаете, как выглядит следующий шаг — на странице цен Thunderbit можно посмотреть актуальное количество кредитов, если хотите понять, во что обойдётся такой переход, а на нашем YouTube-канале есть пошаговые видео, если вам удобнее смотреть, чем читать.
Частые вопросы о скачивании файлов с cURL
Как скачать файл через cURL и сохранить его под конкретным именем?
Используйте -o и укажите нужное имя файла: curl -L -o yourname.ext <url>. Добавьте -L, чтобы редиректы не сорвали загрузку.
Как возобновить неудавшуюся загрузку через cURL?
Запустите curl -C - -LO <url>. Это работает только если сервер поддерживает range-запросы — сначала проверьте через curl -I <url> и посмотрите, есть ли в ответе Accept-Ranges: bytes.
Можно ли через cURL скачивать файлы, требующие входа в систему?
Да, четырьмя основными способами: basic auth (-u user:pass), bearer-токен (-H "Authorization: Bearer <token>"), cookie-сессия (-b cookies.txt) или файл .netrc для сценариев и автоматизации. Полная разбивка и случаи использования — в разделе про аутентификацию выше.
В чём разница между cURL и wget для скачивания файлов?
cURL поддерживает больше протоколов и обычно лучше подходит для скриптов, пайпов и точечных загрузок одного файла или небольшой партии файлов. wget создан для рекурсивного обхода и зеркалирования целых директорий сайта, поэтому он лучше для массового скачивания статических сайтов.
Почему cURL скачивает HTML-страницу вместо настоящего файла?
Обычно виноват один из двух сценариев: вы забыли флаг -L, и сервер отправил вас по редиректу в другое место, либо страница требует JavaScript для рендеринга содержимого — а curl просто не умеет выполнять JS. Во втором случае нужен инструмент с поддержкой рендеринга, а не ещё больше флагов curl.
