Перейти до змістуПерехід API-клієнта з житлового проксі на виділену IP-адресу змінює адресу, яку бачить постачальник API. Це також може вплинути на списки дозволених IP-адрес, підписи запитів, обмеження частоти запитів і повторні спроби. Найбезпечніше змінювати мережевий маршрут по одному клієнту за раз, не змінюючи його облікові дані та поведінку запитів.
Якщо ви плануєте перехід із житлового проксі на виділену IP-адресу для доступу до API, поставтеся до цієї зміни як до мережевого релізу, а не просто як до оновлення налаштувань проксі. Цей матеріал пояснює, як перейти з житлового проксі на виділену IP-адресу: спочатку визначте клієнт, який надсилає запити, потім перевірте вимоги постачальника й протестуйте новий маршрут, перш ніж вимикати старий.
1. Простежте вихідний маршрут API-клієнта
Почніть зі списку клієнтів, які звертаються до API, та середовищ, у яких вони працюють. Виробничий воркер, завдання в середовищі стейджингу й локальний скрипт розробника можуть використовувати різні налаштування проксі, навіть якщо мають спільний обліковий запис API. Перш ніж щось змінювати, зафіксуйте середовище кожного клієнта, місце його розгортання та поточний маршрут вихідного трафіку.
Потім простежте шлях одного запиту від застосунку до постачальника. Перевірте клієнтську бібліотеку, змінні середовища, конфігурацію проксі, мережеві налаштування контейнера або хоста й будь-який вихідний шлюз. Переглядаючи налаштування проксі для API-клієнта, визначте параметр, який задає вихідну адресу, видиму для API, а не обов’язково параметр проксі в головному конфігураційному файлі застосунку.
Не змінюйте маршрутизацію іншого трафіку. Якщо хост надсилає запити до кількох сервісів, спрямуйте через виділену IP-адресу лише API-клієнт, а не весь трафік хоста. Так ви обмежите наслідки можливої помилки: збій API-запиту не порушить роботу агента моніторингу чи іншої інтеграції.
Перш ніж редагувати конфігурацію, зафіксуйте її поточний стан. Зазначте назву клієнта, середовище, адресу хоста призначення та параметр, який керує вихідним трафіком. Такий короткий запис допоможе порівняти старий і новий маршрути, якщо запит завершиться помилкою.
2. Перевірте вимоги постачальника API до списку дозволених IP-адрес
Перевірте документацію облікового запису API або зверніться до служби підтримки, щоб з’ясувати правила формування списку дозволених IP-адрес. Щоб уточнити, як додати IP-адресу до списку дозволених для API, дізнайтеся потрібний формат адреси, процедуру погодження та час, за який зміни набувають чинності, перш ніж спрямовувати виробничі запити.
З’ясуйте, як постачальник застосовує правила списку дозволених адрес до облікового запису та API-ключів, якими ви користуєтеся. Якщо в обліковому записі є кілька API-ключів, перевірте, чи потрібно додавати адресу окремо для кожного з них.
Запитайте, чи можна під час тестування одночасно дозволити поточну адресу житлового проксі й нову адресу. Якщо обидві адреси залишатимуться дозволеними, вам не доведеться переходити на новий маршрут до завершення його перевірки. Якщо постачальник вимагає створити запит на погодження або призначити вікно технічного обслуговування, врахуйте це заздалегідь, а не з’ясовуйте вже під час розгортання.
Якщо обліковий запис API має суворі обмеження доступу, порівняйте адресу, яку очікує постачальник, з адресою, призначеною виділеній IP-адресі. За наявності перевірте її способом, описаним у документації постачальника, або через безпечну тестову кінцеву точку.
3. Додайте виділену IP-адресу, не видаляючи поточну
Коли постачальник підтвердить формат адреси та процедуру погодження, додайте виділену IP-адресу до списку дозволених, залишивши в ньому поточне джерело трафіку. Так ви створите вікно для тестування, протягом якого можна буде використовувати будь-який із маршрутів. Зафіксуйте зміну, зазначивши додану адресу, обліковий запис або API-ключ, якого вона стосується, і статус погодження.
Перш ніж надсилати запит на зміну, перевірте, чи немає помилок у форматі. Одруківка, випадково вказаний діапазон або адреса, додана не до того облікового запису, можуть призвести до незрозумілого результату: новий клієнт і далі отримуватиме помилку авторизації, хоча список дозволених адрес нібито оновлено. Якщо процедура постачальника це дозволяє, попросіть другого фахівця перевірити адресу.
Якщо постачальник API пропонує окремі тестові й виробничі облікові записи, перевірте новий запис саме в тому обліковому записі, яким користується клієнт. Успішний тест у пісочниці не підтверджує, що оновлено список дозволених адрес у виробничому середовищі. Зазначте назви цих облікових записів у примітках до зміни.
Для підключення до проксі використовуйте описаний постачальником спосіб автентифікації й не зберігайте облікові дані у вихідному коді. Посібник із найкращих практик автентифікації через проксі допоможе перевірити, як клієнт передає облікові дані проксі, не плутаючи їх з обліковими даними API.
4. Спрямуйте один API-клієнт через виділену IP-адресу
Для першого тесту виберіть клієнт із низьким рівнем ризику, наприклад воркер у середовищі стейджингу, який надсилає типові запити, але не вносить змін, видимих клієнтам. Змініть лише налаштування вихідного трафіку цього клієнта. Не змінюйте його API-ключ, заголовки запитів, формування тіла запиту й параметри тайм-ауту — так мережевий маршрут залишиться основною змінною.
Зробіть новий маршрут помітним у конфігурації. Наприклад, використайте змінну середовища з чіткою назвою або окремий блок конфігурації клієнта, а не перезаписуйте спільне налаштування проксі, яким користуються кілька застосунків. Конкретний параметр залежить від середовища виконання та клієнтської бібліотеки; перш ніж розгортати зміни, перевірте, як бібліотека працює з проксі й прямими підключеннями.
Під час тестування збережіть доступ до старого маршруту. Відкат має зводитися до відновлення попереднього налаштування вихідного трафіку клієнта, а не до повторного створення облікових даних чи зміни коду API-запитів. Не змінюйте облікові дані.
Якщо клієнт використовує HTTP-проксі або SOCKS5-проксі для підключення до виділеної IP-адреси, звірте протокол і порт з інструкціями постачальника проксі. Відмінності, описані в цьому посібнику про SOCKS5-проксі та HTTP-проксі, можуть стати в пригоді, якщо клієнтська бібліотека підтримує один протокол, але не інший. Перш ніж вибирати, перевірте фактичні вимоги бібліотеки.
5. Перевірте автентифікацію API та підписування запитів
Надішліть через виділену IP-адресу кілька типових запитів. Додайте запит на читання, а якщо API дозволяє безпечне тестування — і запит, який використовує той самий механізм автентифікації та підписування, що й виробничий клієнт. Для першої перевірки використовуйте кінцеву точку, яка не змінює дані; не тестуйте, створюючи або скасовуючи реальне замовлення.
Зафіксуйте код відповіді й текст помилки від постачальника. Відповідь 401 або 403 може вказувати на проблеми з обліковими даними, правами доступу чи правилом для IP-адрес, але остаточно визначити причину допоможе відповідь постачальника. Якщо API використовує підписані запити, порівняйте метод, шлях, часову мітку, тіло запиту та підписані заголовки в запитах через старий і новий маршрути. Зміна мережевого маршруту не має вимагати нового підпису, але редагування конфігурації клієнта може ненавмисно змінити формування запиту.
Якщо запит через житловий проксі успішний, а через виділену IP-адресу завершується помилкою, перевірте список дозволених адрес облікового запису та права доступу на рівні ключа. Дотримуйтеся документації постачальника щодо правил доступу, прив’язаних до IP-адрес.
Не змішуйте автентифікацію проксі з автентифікацією API. Облікові дані проксі дають клієнту змогу користуватися проксі, а облікові дані API авторизують запит до сервісу. Якщо в журналі обидва типи помилок позначено просто як «помилка автентифікації», це може ускладнити пошук причини. Збирайте достатньо даних, щоб визначити, на якому етапі підключення чи обробки запиту виникла помилка.
6. Перевірте роботу API за реального навантаження
Один успішний запит підтверджує лише базову доступність, а не готовність до виробничої роботи. Запустіть вибраний клієнт зі звичним шаблоном запитів і перевірте коди відповідей, затримки, тайм-аути та поведінку повторних спроб. Якщо клієнт надсилає запити і на читання, і на запис, перевірте обидва типи операцій на безпечних записах або в тестовому середовищі, схваленому постачальником.
Зверніть увагу на відповіді про перевищення обмеження частоти запитів. З’ясуйте, яке саме обмеження діє та до чого воно застосовується, а не припускайте, що для виділеної IP-адреси передбачено окрему квоту. Перевірте, чи обробляє клієнт таку відповідь відповідно до інструкцій постачальника, зокрема чи враховує потрібний час очікування або заголовок відповіді.
Перш ніж збільшувати трафік, перевірте повторні спроби та ідемпотентність. Якщо запит завершується тайм-аутом уже після того, як його отримав постачальник, автоматичний повтор може вдруге виконати операцію запису, якщо API не підтримує ключ ідемпотентності або інший спосіб уникнути дублювання. Перевірте цю поведінку на тому самому шаблоні запитів, який клієнт використовує зазвичай, і з’ясуйте, що API повертає на повторний запит.
Також перевірте тайм-аути підключення та повторне використання з’єднань. Клієнт, який відкриває нове з’єднання для кожного запиту, може поводитися інакше, ніж клієнт із постійними з’єднаннями, особливо якщо на маршруті є проксі або шлюз. Фіксуйте помилки самого API окремо від помилок DNS, підключення та проксі, щоб команда могла визначити, на якому рівні потрібне втручання.
7. Переведіть решту клієнтів і вимкніть старий маршрут
Коли перший клієнт успішно пройде всі перевірки, по черзі переведіть решту. Змінюйте одне середовище або один сервіс за раз, а потім перевіряйте, чи запити йдуть через виділену IP-адресу та чи залишається частота помилок, пов’язаних з API, у межах звичних для команди показників. Не змінюйте все одночасно: так буде складніше визначити причину збоїв.
Ведіть простий журнал змін, зазначаючи назву кожного клієнта, час розгортання, маршрут і результат перевірки. Якщо один із клієнтів не працює, ці записи допоможуть відрізнити проблему його конфігурації від проблеми зі списком дозволених адрес у постачальника. Зупиніть розгортання, доки причина не стане зрозумілою, замість того щоб застосовувати ту саму зміну в інших середовищах.
Видаляйте адресу житлового проксі зі списку дозволених лише після того, як підтвердите перехід усіх потрібних клієнтів на виділену IP-адресу та завершиться період, протягом якого можливий відкат. Уточніть у постачальника API, чи потребує видалення адреси погодження та чи набуває воно чинності негайно. Після видалення старої адреси надішліть по одному тестовому запиту з кожного переведеного середовища.
Збережіть конфігурацію старого маршруту в контрольованих записах для відкату, але не залишайте непотрібний доступ увімкненим без вагомої причини. Якщо під час подальшого розгортання знову знадобиться житловий проксі, відновіть доступ у звичайному порядку, передбаченому постачальником, а не покладайтеся на непогоджений виняток.