Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Сразу к делу: pacman ходит через прокси благодаря libcurl, а libcurl читает переменные окружения http_proxy, https_proxy и all_proxy. Экспортируй нужную переменную в оболочке или пропиши её в /etc/environment, и pacman начнёт скачивать пакеты через прокси. Отдельной настройки прокси в конфигах pacman нет, всё решают переменные окружения.
pacman скачивает пакеты и базы через библиотеку libcurl. Это та же библиотека, что работает в curl, поэтому правила прокси у них общие. При каждом запросе libcurl смотрит переменные окружения: http_proxy используется для адресов с http://, https_proxy для адресов с https://, а all_proxy подходит для любых протоколов, когда конкретная переменная не задана.
Переменные регистронезависимы: libcurl понимает и http_proxy, и HTTP_PROXY. Но есть нюанс. Многие программы намеренно игнорируют HTTP_PROXY в верхнем регистре, потому что заглавную версию можно подсунуть через HTTP-заголовки в CGI-окружении. Поэтому привыкай писать переменные строчными буквами: http_proxy, https_proxy, all_proxy. Так они сработают везде, включая pacman.
Важно понимать: pacman не читает файл ~/.curlrc. Этот файл разбирает только сама утилита curl, а библиотека libcurl работает с переменными окружения напрямую. Поэтому настройка прокси в .curlrc на pacman не повлияет, как бы аккуратно ты её ни оформил.
Полный набор выглядит так:
export http_proxy=http://127.0.0.1:8080
export https_proxy=http://127.0.0.1:8080
export all_proxy=socks5://127.0.0.1:1080
export no_proxy=localhost,127.0.0.1
Что делает каждая из них:
http_proxy: прокси для запросов по http://. Зеркала Arch отдают пакеты по http, поэтому эта переменная нужна почти всегда.https_proxy: прокси для https://. Пригодится для AUR-помощников и загрузки по защищённому протоколу.all_proxy: запасной вариант для всех протоколов. Если http_proxy и https_proxy не заданы, libcurl использует all_proxy.no_proxy: список хостов, для которых прокси не нужен. Хосты перечисляются через запятую, без пробелов.Значения переменных: обычные URL. Например, http://127.0.0.1:8080 для локального HTTP-прокси и socks5://127.0.0.1:1080 для SOCKS5-прокси. Если прокси требует логин и пароль, пиши их прямо в адресе: http://user:password@proxy.example.com:3128.
Переменные должны быть экспортированы, а не просто присвоены. Запись http_proxy=http://127.0.0.1:8080 без export создаст переменную только внутри текущей оболочки, и дочерние процессы, включая pacman, её не увидят. Проверить, что переменная попала в окружение, можно командой env | grep proxy.
Способов три, и они отличаются областью действия.
Просто экспортируй переменные перед запуском pacman:
export https_proxy=http://127.0.0.1:8080
sudo pacman -Syu
Переменные живут, пока открыт терминал. Закрыл окно, всё пропало. Удобно для разовой проверки.
Файл /etc/environment читается при входе в систему, поэтому переменные из него попадают во все программы, включая pacman под sudo:
sudo tee -a /etc/environment <<'EOF'
http_proxy=http://127.0.0.1:8080
https_proxy=http://127.0.0.1:8080
no_proxy=localhost,127.0.0.1
EOF
После правки выйди из сессии и зайди заново, чтобы переменные подхватились. Это самый надёжный способ для постоянного прокси.
Можно добавить экспорт в ~/.bashrc или ~/.zshrc. Тогда переменные появятся в каждой новой оболочке. Но учти: при sudo pacman окружение пользователя не передаётся автоматически, поэтому для pacman этот способ работает только с sudo -E или если переменные прописаны в /etc/environment.
Если не хочешь трогать /etc/environment, а pacman запускаешь через sudo, добавь в ~/.bashrc алиас: alias pacman='sudo -E pacman'. Флаг -E сохраняет окружение пользователя, и переменные прокси дойдут до pacman. Минус в том, что через sudo передаётся всё окружение, а не только прокси.
Важный момент: файла ~/.config/pacman/makepkg.conf не существует. Конфиг makepkg лежит в /etc/makepkg.conf, и прокси в нём задаётся не через переменные окружения. Об этом ниже.
Самый простой способ: запустить прокси с логами и посмотреть, приходят ли запросы. Например, tinyproxy пишет каждый запрос в лог. Или следи за соединениями:
ss -tnp | grep 8080
Если pacman реально ходит через прокси, ты увидишь установленные соединения с адресом прокси. Дополнительно можно сравнить скорость: с прокси и без него. Подробнее про медленные зеркала и их диагностику читай в статье «Медленные зеркала: reflector».
Перед тем как проверять pacman, убедись, что прокси вообще работает. Проще всего проверить его утилитой curl: curl -x http://127.0.0.1:8080 https://archlinux.org. Если ответ приходит, прокси жив, и можно переходить к pacman.
Ещё один способ: временно задать заведомо неверный адрес прокси:
export https_proxy=http://127.0.0.1:1
sudo pacman -Syu
Если pacman ругнётся на недоступный прокси, значит переменные работают. Если обновление пройдёт как ни в чём не бывало, прокси не используется.
libcurl умеет работать с HTTP, HTTPS и SOCKS-прокси.
http://host:port. Подходит для корпоративных сетей и домашних кэширующих прокси.https://host:port.socks4://host:port и socks5://host:port. SOCKS работает на уровне TCP, поэтому через него можно ходить даже на адреса, которые HTTP-прокси не пропускает.http://user:pass@host:port. Спецсимволы в пароле кодируй как в URL, например %40 вместо @.Есть ещё прозрачные прокси, которые перехватывают трафик на уровне сети без настройки клиента. Для pacman они невидимы: он просто ходит напрямую, а прокси подменяет соединение сам. Такие схемы обычно настраиваются на роутере или шлюзе и не требуют переменных окружения.
Отдельно стоит упомянуть кэширующие прокси вроде Squid или apt-cacher-ng. Они сохраняют скачанные пакеты у себя, и повторные запросы отдают из кэша. Для Arch это удобно, если у тебя несколько машин в локальной сети: один раз скачал пакет, остальные получили его с прокси. Настройка зеркал для такой схемы описана в статье «Настройка зеркал в Arch Linux».
Если зеркало лежит в локальной сети, гонять трафик через внешний прокси бессмысленно. Список исключений задаётся через no_proxy:
export no_proxy=localhost,127.0.0.1,192.168.1.0/24
libcurl сравнивает адрес хоста со списком и для совпавших идёт напрямую. Формат простой: хосты и подсети через запятую, без пробелов. Звёздочка * означает «не использовать прокси вообще».
Обрати внимание: no_proxy сравнивает адрес по имени хоста, а не по IP. Если зеркало прописано в mirrorlist как http://mirror.local, в no_proxy пиши именно mirror.local, а не его IP-адрес. Иначе libcurl не совпадёт запись и всё равно пойдёт через прокси.
Нет. Если ты подключил свой репозиторий по file://, pacman читает файлы прямо с диска, сеть не задействуется, а значит, и прокси не нужен. Переменные окружения в этом случае просто игнорируются. Как собрать и подключить такой репозиторий, разобрано в статье «Свой репозиторий: repo-add».
Кстати, тот же принцип работает для любых локальных источников: пакеты из кэша pacman, собранные вручную PKGBUILD’ы, файлы на смонтированном диске. Прокси нужен только там, где есть сетевой запрос.
makepkg собирает пакеты и тоже скачивает исходники, часто через curl или wget. Прокси для него задаётся теми же переменными окружения. Прописать их можно прямо в /etc/makepkg.conf:
export http_proxy=http://127.0.0.1:8080
export https_proxy=http://127.0.0.1:8080
Строки с export в начале файла сработают при каждом запуске makepkg. Но если прокси нужен всей системе, проще один раз прописать переменные в /etc/environment, и makepkg подхватит их сам.
Потому что многие программы, включая libcurl в некоторых сборках, намеренно не читают HTTP_PROXY заглавными буквами. Это защита от подмены переменной через HTTP-заголовки. Решение простое: используй строчные http_proxy и https_proxy. То же самое касается HTTPS_PROXY и ALL_PROXY. Правило одно: всегда пиши переменные строчными, тогда поведение будет одинаковым во всех программах.
Экспортируй переменные в текущей оболочке перед запуском pacman. Действие закончится вместе с закрытием терминала. Для постоянного эффекта только для pacman можно обернуть команду в скрипт или алиас. Алиас с sudo -E тоже подойдёт, но помни, что он передаёт всё окружение.
Да. libcurl поддерживает SOCKS4 и SOCKS5. Задай all_proxy=socks5://host:port, и pacman пойдёт через него. Учти, что для https_proxy адрес тоже можно указать как socks5. Если прокси требует аутентификацию, укажи её в адресе: socks5://user:pass@host:port.
Нет. Добавь адрес зеркала в no_proxy, и libcurl пойдёт к нему напрямую. Иначе трафик к локальному зеркалу пойдёт через внешний прокси, что медленно и бессмысленно. То же правило действует для своего репозитория по file://: там сети нет вообще.
Проверь, что https_proxy указывает на рабочий прокси и что прокси пропускает TLS-трафик. Иногда помогает переключение на socks5. Похожие ошибки соединения у AUR-помощников разобраны в статье «AUR: ошибки TLS и EOF». Ещё одна частая причина: устаревший список зеркал. Обнови mirrorlist и повтори обновление.
Прокси для pacman настраивается переменными окружения, потому что скачивание пакетов делает libcurl. Экспортируй http_proxy и https_proxy в оболочке или пропиши их в /etc/environment, добавь локальные зеркала в no_proxy, и pacman будет ходить через прокси без правки своих конфигов. Для makepkg те же переменные можно прописать в /etc/makepkg.conf. Проверка простая: посмотри соединения через ss или задай заведомо неверный адрес прокси.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии