Перейти к содержимомуПри переводе API-клиента с резидентного прокси на выделенный IP-адрес меняется адрес, который видит поставщик API. Это также может повлиять на списки разрешённых адресов, подписи запросов, ограничения частоты запросов и повторные попытки. Безопаснее всего менять сетевой маршрут по одному клиенту за раз, не меняя его учётные данные и поведение запросов.
Если вы выясняете, как перевести API с резидентного прокси на выделенный IP-адрес, рассматривайте это как изменение сетевой инфраструктуры, а не просто обновление настройки прокси. Сначала определите, какой клиент отправляет запросы, затем уточните правила поставщика API и проверьте новый маршрут, прежде чем отключать старый.
1. Проследите исходящий маршрут API-клиента
Для начала перечислите клиентов, которые обращаются к API, и укажите, где работает каждый из них. У рабочего процесса в production, задачи в staging и локального скрипта разработчика могут быть разные настройки прокси, даже если они используют одну учётную запись API. Прежде чем что-либо менять, зафиксируйте среду каждого клиента, место его развёртывания и текущий маршрут выхода в интернет.
Затем проследите путь одного запроса от приложения до поставщика API. Проверьте клиентскую библиотеку, переменные среды, настройки прокси, сетевые параметры контейнера или хоста, а также любые исходящие шлюзы. Важно найти настройку, которая определяет исходный адрес, видимый API, — это не обязательно параметр прокси в основном конфигурационном файле приложения.
Не затрагивайте трафик, не относящийся к задаче. Если хост отправляет запросы нескольким сервисам, направьте через выделенный IP только API-клиент, а не меняйте настройки прокси для всего хоста. Так вы ограничите последствия ошибки: сбой API-запроса не должен нарушить работу агента мониторинга или другой интеграции.
Перед внесением изменений запишите текущую конфигурацию. Укажите название клиента, среду, целевой хост и настройку, которая управляет исходящим трафиком. Такая запись поможет сравнить старый и новый маршруты, если запрос завершится ошибкой.
2. Уточните требования поставщика API к списку разрешённых IP-адресов
Изучите документацию учётной записи API или обратитесь в службу поддержки, чтобы выяснить правила работы списка разрешённых адресов. Прежде чем направлять production-запросы, уточните допустимый формат адреса, порядок согласования и сроки вступления изменений в силу.
Узнайте, как поставщик применяет правила списка разрешённых адресов к используемой учётной записи и API-ключам. Если у учётной записи несколько API-ключей, проверьте, нужно ли добавлять адрес для каждого ключа отдельно.
Спросите, можно ли на время тестирования оставить в списке разрешённых адресов текущий IP резидентного прокси. Если разрешены оба источника, можно проверить новый маршрут без немедленного переключения. Если поставщик требует оформить заявку на согласование или выбрать окно обслуживания, учтите это заранее, а не выясняйте во время развёртывания.
Для учётной записи API со строгими ограничениями доступа сравните адрес, который ожидает увидеть поставщик, с адресом, назначенным выделенному IP. Если такая возможность есть, проверьте адрес способом, описанным в документации поставщика, или с помощью безопасного тестового эндпоинта.
3. Добавьте выделенный IP, не удаляя текущий источник
Когда поставщик подтвердит формат адреса и порядок согласования, добавьте выделенный IP в список разрешённых адресов учётной записи, оставив текущий источник без изменений. Так у вас появится окно для тестирования, в течение которого можно использовать любой из маршрутов. Зафиксируйте изменение: укажите добавленный адрес, учётную запись или API-ключ, к которому он относится, и статус согласования.
Чтобы понять, как добавить IP в список разрешённых для API, сначала проверьте требования поставщика к формату записи и учётной записи. Опечатка, случайно указанный диапазон или добавление адреса не к той учётной записи могут привести к непонятной ситуации: новый клиент продолжит получать ошибку авторизации, хотя список разрешённых адресов, судя по всему, обновлён. Если процедура поставщика это допускает, попросите второго специалиста проверить адрес.
Если поставщик API предоставляет отдельные тестовые и production-учётные записи, убедитесь, что новую запись добавили именно в ту учётную запись, которой пользуется клиент. Успешный тест в песочнице не подтверждает, что список разрешённых адресов в production обновлён. Указывайте названия этих учётных записей в примечаниях к изменениям.
При подключении к прокси используйте рекомендованный поставщиком способ аутентификации и не храните учётные данные в исходном коде. В руководстве по безопасной аутентификации в прокси описано, как проверить передачу прокси-учётных данных клиентом, не перепутав их с данными для доступа к API.
4. Направьте один API-клиент через выделенный IP
Для первого теста выберите клиента с низким уровнем риска — например, staging-воркер, который отправляет типичные запросы, но не выполняет действий, влияющих на пользователей. Измените только настройки исходящего трафика этого клиента. Оставьте без изменений его API-ключ, заголовки запросов, формирование тела запроса и параметры тайм-аута, чтобы основным изменившимся фактором был сетевой маршрут.
Такая настройка выделенного IP для API должна быть различима в конфигурации. Например, используйте переменную среды с понятным названием или отдельный блок настроек клиента вместо перезаписи общей настройки прокси, которой пользуются несколько приложений. Конкретный параметр зависит от среды выполнения и клиентской библиотеки. Перед развёртыванием выясните, как библиотека работает с прокси и прямыми подключениями.
Во время тестирования оставьте старый маршрут доступным. Для отката достаточно вернуть прежнюю настройку исходящего трафика клиента — пересоздавать учётные данные или менять код API-запросов не должно потребоваться. Не меняйте учётные данные.
Если для подключения к выделенному IP клиент использует HTTP-прокси или SOCKS5-прокси, сверьте протокол и порт с инструкциями поставщика прокси. Сравнение в этом руководстве по SOCKS5- и HTTP-прокси поможет разобраться, если клиентская библиотека поддерживает один протокол, но не другой. Прежде чем выбирать протокол, проверьте реальные требования библиотеки.
5. Проверьте аутентификацию API и подпись запросов
Отправьте через выделенный IP несколько типичных запросов. Добавьте запрос на чтение и, если API позволяет безопасно тестировать такие операции, запрос, который проходит тот же путь аутентификации и подписания, что и production-клиент. Для первой проверки используйте эндпоинт, не изменяющий данные. Не проверяйте работу системы, создавая или отменяя реальный заказ.
Зафиксируйте код ответа и текст ошибки от поставщика. Ответы 401 или 403 могут указывать на проблему с учётными данными, правами доступа или правилом для IP-адреса, но точную причину нужно определять по ответу поставщика. Если API использует подписанные запросы, сравните метод, путь, временную метку, тело запроса и подписанные заголовки при работе через старый и новый маршруты. Смена сетевого маршрута не должна требовать новой подписи, но изменение конфигурации клиента может случайно повлиять на формирование запроса.
Если через резидентный прокси запрос проходит, а через выделенный IP — нет, проверьте список разрешённых адресов учётной записи и разрешения для API-ключа. Для любых правил доступа, привязанных к IP, следуйте документации поставщика.
Не смешивайте аутентификацию прокси с аутентификацией API. Данные прокси позволяют клиенту пользоваться прокси, а учётные данные API дают право отправлять запросы сервису. Если в журнале обе ошибки обозначены просто как «ошибка аутентификации», поиск причины может затянуться. Записывайте достаточно подробностей, чтобы определить, на каком этапе — подключения или обработки запроса — возникла ошибка.
6. Проверьте работу API при обычной нагрузке
Один успешный запрос подтверждает лишь базовую доступность, но не готовность к работе в production. Запустите выбранный клиент с обычным шаблоном запросов и проверьте коды ответов, задержки, тайм-ауты и повторные попытки. Если клиент отправляет запросы на чтение и запись, протестируйте оба типа операций на безопасных данных или в одобренной поставщиком тестовой среде.
Обратите внимание на ответы об ограничении частоты запросов. Уточните, какое ограничение действует и к чему оно применяется, а не предполагайте, что у выделенного IP отдельная квота. Сверьте обработку такого ответа клиентом с инструкциями поставщика, в том числе с требованиями к интервалу ожидания и заголовкам ответа.
Прежде чем увеличивать трафик, проверьте повторные попытки и идемпотентность. Если запрос достиг поставщика, но завершился тайм-аутом, автоматический повтор может повторно выполнить операцию записи — если API не поддерживает ключ идемпотентности или другой способ предотвращения дублирования. Проверьте это на том же шаблоне запросов, который клиент использует в обычной работе, и выясните, что API возвращает при повторной отправке запроса.
Также проверьте тайм-ауты подключений и повторное использование соединений. Клиент, который устанавливает новое соединение для каждого запроса, может вести себя иначе, чем клиент с постоянными соединениями, особенно если в цепочке есть прокси или шлюз. Отдельно отслеживайте ошибки API и ошибки DNS, подключения и прокси, чтобы команда могла определить, на каком уровне возникла проблема.
7. Переведите остальные клиенты и отключите старый маршрут
После того как первый клиент пройдёт проверки, переводите остальные клиенты по одному. За раз меняйте настройки только одной среды или службы, а затем проверяйте, что её запросы идут через выделенный IP и что доля ошибок, связанных с API, не превышает обычные рабочие показатели команды. Не переключайте всё сразу: в противном случае будет сложнее локализовать сбой.
Ведите простой журнал изменений: указывайте название клиента, время развёртывания, маршрут и результат проверки. Если один клиент не работает, записи помогут понять, связана ли проблема с его конфигурацией или с общим списком разрешённых адресов у поставщика. Приостановите переключение, пока причина не станет ясна, — не переносите те же изменения в другие среды.
Удаляйте резидентный прокси из списка разрешённых адресов, только когда все нужные клиенты будут переведены на выделенный IP и срок, отведённый на откат, закончится. Уточните у поставщика API, нужно ли согласовывать удаление записи и когда оно вступит в силу. После удаления старой записи отправьте по одному запросу из каждой переведённой среды.
Сохраните настройки старого маршрута в контролируемой записи для отката, но не оставляйте неиспользуемый доступ включённым без необходимости. Если в будущем при развёртывании снова понадобится резидентный прокси, запросите доступ обычным способом через поставщика, а не полагайтесь на незадокументированное исключение.