Перейти к содержимомуКак использовать прокси в GitHub Codespaces при ограниченном доступе к сети
Среда GitHub Codespaces запускает контейнер разработки на удалённом сервере, а браузер, в котором она отображается, работает на вашем устройстве. Это важно: настройка прокси внутри контейнера может направлять через него загрузку пакетов из Codespace, но не меняет автоматически способ, которым локальный браузер подключается к сайтам.
Если установка зависимости не удаётся из-за корпоративного брандмауэра, сначала выясните, какое именно подключение блокируется. От этого зависит, где нужно настроить прокси и какие адреса должна разрешить ваша организация. Если вы выясняете, как настроить прокси в GitHub Codespaces, начните с определения источника сетевого запроса.
1. Определите, для какого трафика Codespaces нужен прокси
Уточните, какая именно операция завершается с ошибкой. Установка пакета Python с помощью pip, загрузка зависимости Node.js через npm и скачивание консольной утилиты из терминала — это запросы программ, работающих в контейнере разработки. А вкладка браузера, открытая на ноутбуке, использует сетевое подключение самого ноутбука.
Это различие поможет сэкономить время. Если сайт не открывается в локальном браузере, добавление HTTPS_PROXY в Codespace может ничего не изменить. И наоборот: если команда npm install завершается ошибкой в терминале Codespace, прокси, настроенный только на ноутбуке, может не помочь.
Запишите, какая программа выдала ошибку, к какому адресу она обращалась и откуда пришёл запрос: из терминала, расширения редактора или локального браузера. Например, ошибка при выполнении pip install указывает на трафик контейнера, а сбой при открытии страницы входа в локальном браузере — на локальную сеть или настройки браузера.
Не расширяйте область действия без необходимости. Если заблокирован только один реестр пакетов, маршрутизация всего трафика через прокси может вызвать лишние сбои, особенно если внутренние сервисы должны быть доступны напрямую.
2. Узнайте, что разрешает прокси вашей организации
Запросите у администратора сети имя хоста и порт прокси, нужный протокол и способ аутентификации. Также уточните, требуется ли имя пользователя и пароль, клиентский сертификат или сертификат центра сертификации, установленный в контейнере. Не пытайтесь определить эти параметры по настройкам прокси на другом устройстве.
Уточните, какие адреса разрешены для конкретной задачи. Менеджеру пакетов может понадобиться доступ к реестру, а установщик утилиты может загружать файлы с отдельного сервера релизов. Администратор подтвердит, какие имена хостов разрешены. Запишите их до начала диагностики, чтобы отличить блокировку адреса от неверного адреса прокси.
Узнайте, включена ли проверка HTTPS-трафика. При такой проверке прокси может предъявлять сертификаты, выпущенные вашей организацией, вместо публичных сертификатов, которым доверяет программа. Сертификат организации и утверждённый способ его установки должен предоставить администратор — не используйте сертификат, скопированный из сообщения об ошибке.
Если вы сравниваете типы прокси или настраиваете доступ для других инструментов, рекомендации по безопасной работе с учётными данными приведены в руководстве по безопасной аутентификации через прокси. О выборе способа маршрутизации трафика читайте в статье как выбрать VPN: VPN и прокси настраиваются в Codespaces по-разному.
3. Настройте переменные прокси для контейнера разработки
Многие консольные программы используют переменные окружения HTTP_PROXY и HTTPS_PROXY. Именно переменные HTTP_PROXY и HTTPS_PROXY в Codespaces обычно задают адрес прокси для приложений в окружении контейнера разработки. Укажите адрес в формате, который предоставил администратор. Обычно значение выглядит так: http://proxy.example.net:8080, но используйте фактические протокол, имя хоста и порт вашей организации.
Для адресов, к которым следует обращаться в обход прокси, задайте NO_PROXY — например, для одобренных внутренних сервисов или локальных адресов. Точный список зависит от сети и используемых программ. Слишком широкое значение может направить внутренние запросы по нежелательному маршруту, а слишком узкое — оставить запрос к заблокированному адресу без прокси.
Для быстрой временной проверки можно задать переменные в сеансе терминала перед запуском команды. Так удобно проверить, сработает ли установка пакета, но этот способ не гарантирует настройку для всех терминалов и будущих сеансов Codespaces. Синтаксис команд зависит от оболочки. Не вставляйте URL прокси с учётными данными в команду, которая может сохраниться в истории оболочки.
Чтобы настройка проекта воспроизводилась, добавьте нечувствительные к разглашению параметры в конфигурацию контейнера разработки, используемую репозиторием, например в подходящий файл Dev Container или скрипт настройки. Не храните пароли и токены в отслеживаемых файлах. Если нужны учётные данные, используйте одобренный организацией способ передачи секретов и уточните, какие процессы смогут к ним обращаться.
Не все приложения обязательно используют эти переменные. Некоторые читают варианты в нижнем регистре, некоторые используют собственные файлы конфигурации, а другие вообще игнорируют переменные окружения. Проверяйте именно ту команду, которая завершилась с ошибкой: наличие HTTPS_PROXY ещё не доказывает, что весь трафик Codespace проходит через прокси.
4. Сохраните настройки прокси после пересоздания Codespace
Настройка, заданная в одном терминале, может исчезнуть после его закрытия или пересоздания Codespace. Чтобы необходимые проекту несекретные параметры сохранялись, используйте конфигурацию уровня репозитория, которая применяется при создании контейнера разработки. Тогда коллега, открывший тот же проект, получит базовую настройку без необходимости добавлять в репозиторий личные учётные данные.
Если прокси нужен только вашей учётной записи или значение конфиденциально, может подойти персональная настройка. Прежде чем использовать этот способ, проверьте политики вашей организации и доступные настройки Codespaces: администратор может ограничивать персональную конфигурацию, секреты или применение отдельных возможностей контейнеров разработки.
После изменения настроек пересоздайте Codespace, если это влияет на создание контейнера, затем откройте новый терминал и проверьте переменные. Пересоздание — полезная проверка: если после него настройка прокси исчезла, вероятно, она была добавлена только в предыдущую оболочку, а не в постоянный источник конфигурации.
Храните общие настройки отдельно от секретов. В репозитории можно описать имена переменных прокси и нужный формат, но настоящий пароль следует передавать через одобренный механизм для работы с секретами. Так обычный коммит не раскроет учётные данные всем, кто может просматривать историю проекта.
5. Если требуется, настройте доверие к сертификату прокси
Если HTTPS-запросы завершаются ошибкой проверки сертификата, а организация подтвердила, что проверка HTTPS-трафика включена, контейнеру может понадобиться сертификат центра сертификации организации. Получите официальный сертификат и инструкции по его установке у администратора. Не отключайте проверку сертификатов в качестве обходного решения: это может скрыть проблему перехвата трафика, а не устранить её.
Процедура установки зависит от операционной системы и базового образа контейнера. В образах на базе Debian, Alpine и специализированных языковых образах наборы сертификатов могут обрабатываться по-разному. Также уточните, нужно ли добавлять сертификат при создании контейнера, чтобы он сохранился после пересоздания.
После установки проверьте обычный HTTPS-запрос к разрешённому адресу той же программой, которая выдала ошибку. Если браузер работает, а консольная программа всё ещё сообщает о недоверенном издателе, у неё может быть отдельное хранилище сертификатов или собственная настройка. Прежде чем менять параметры доверия, уточните у администратора, какой файл сертификата и формат следует использовать в контейнере.
6. Отдельно проверьте Git и инструменты разработки
Сначала выполните простой запрос к адресу, который одобрил администратор. Затем проверьте менеджер пакетов или инструмент, вызвавший ошибку. Успешный запрос одной команды не означает, что Git, pip, npm и специализированные установщики для языков программирования одинаково используют прокси.
Для Git проверьте, использует ли установленная версия переменные окружения прокси в вашей конфигурации. Если нет, для Git может потребоваться отдельная настройка прокси. Не указывайте пароль непосредственно в файле конфигурации Git, который может попасть в коммит или журналы. Вместо этого используйте одобренный организацией способ работы с учётными данными.
Для менеджеров пакетов проверьте и настройки прокси, и адрес настроенного реестра. Менеджеру, работающему с внутренним реестром, может не понадобиться тот же внешний адрес, что и при прямой загрузке, а инструмент, скачивающий архив релиза, может обращаться к другому хосту. Сравните адрес из сообщения об ошибке со списком разрешённых адресов.
Если вы выясняете, как установить пакеты в Codespaces за корпоративным прокси, проверьте переменные окружения, адрес реестра пакетов и доступность нужного хоста: для разных менеджеров пакетов и установщиков настройки могут отличаться.
Запишите, какие проверки прошли, какие завершились ошибкой и какой хост был задействован. Такая краткая сводка даст администратору полезную информацию — например: «Git подключается к разрешённому хосту, но прокси отклоняет запрос к реестру пакетов», — вместо расплывчатого сообщения о том, что в Codespaces нет интернета.
7. Диагностируйте сбои подключения, не раскрывая учётные данные
Выполните безопасную проверку подключения к разрешённому адресу и определите, связана ли ошибка с разрешением DNS-имени, тайм-аутом, аутентификацией на прокси, блокировкой адреса или проверкой сертификата. Каждая причина требует своих дальнейших действий. Например, тайм-аут — это не то же самое, что отказ в аутентификации.
Проверьте, что имя хоста и порт прокси совпадают со значениями, предоставленными администратором, и что переменная задана именно в том сеансе терминала, где вы запускаете проверку. Если прокси требует аутентификации, доступ может не работать из-за отсутствующих или устаревших учётных данных, даже если адрес указан правильно.
Прежде чем отправлять кому-либо вывод терминала, удалите имена пользователей, пароли, токены и URL с учётными данными. В ошибках прокси может содержаться полный адрес запроса, а история оболочки может сохранять команды с секретами. Вместо этого сообщите тип ошибки, имя хоста назначения, название инструмента и время сбоя — этих данных часто достаточно, чтобы специалисты сетевой поддержки проверили журналы.
Если прокси работает в одном Codespace, но не в другом, сравните конфигурацию контейнера, образ операционной системы, переменные окружения и настройки сертификатов. Вносите изменения по одному и повторяйте одну и ту же проверку. Так будет проще определить, вызвана ли проблема отсутствующей переменной, заблокированным адресом или различиями в хранилищах сертификатов.