Przejdź do treściPrzeniesienie klienta API z proxy rezydencyjnego na dedykowany adres IP zmienia adres widoczny dla dostawcy API. Jeśli zastanawiasz się, jak zmienić adres IP dla klienta API, pamiętaj, że zmiana może też wpłynąć na listy dozwolonych adresów IP, podpisy żądań, limity zapytań i ponawianie prób. Najbezpieczniej zmieniać trasę sieciową po jednym kliencie, nie zmieniając przy tym jego danych uwierzytelniających ani sposobu wysyłania żądań.
Planując przeniesienie dostępu do API z proxy rezydencyjnego na dedykowany adres IP, potraktuj przeniesienie API z proxy na dedykowany adres IP jak wdrożenie nowej trasy sieciowej, a nie tylko aktualizację ustawień proxy. Najpierw ustal, który klient wysyła żądania, następnie sprawdź wymagania dostawcy i przetestuj nową trasę, zanim wyłączysz dotychczasową.
1. Prześledź trasę wychodzącą klienta API
Zacznij od sporządzenia listy klientów korzystających z API i ustalenia, gdzie każdy z nich działa. Worker produkcyjny, zadanie w środowisku testowym i lokalny skrypt programisty mogą korzystać z różnych ustawień proxy, nawet jeśli używają tego samego konta API. Zanim wprowadzisz zmiany, zanotuj środowisko każdego klienta, miejsce wdrożenia i obecną trasę ruchu wychodzącego.
Następnie prześledź trasę pojedynczego żądania — od aplikacji do dostawcy. Sprawdź bibliotekę klienta, zmienne środowiskowe, konfigurację proxy, ustawienia sieciowe kontenera lub hosta oraz wszelkie bramy ruchu wychodzącego. Liczy się ustawienie, które określa adres źródłowy widoczny dla API — niekoniecznie ustawienie proxy w głównym pliku konfiguracyjnym aplikacji.
Nie obejmuj zmianami niezwiązanego ruchu. Jeśli host wysyła żądania do kilku usług, skieruj przez dedykowany adres IP tylko klienta API, zamiast zmieniać ustawienia proxy dla całego hosta. Ogranicza to skutki ewentualnego błędu: nieudane żądanie do API nie powinno zakłócić działania agenta monitorującego ani innej integracji.
Przed edycją zapisz obecną konfigurację. Uwzględnij nazwę klienta, środowisko, host docelowy i ustawienie sterujące ruchem wychodzącym. Taka krótka notatka ułatwi porównanie starej i nowej trasy, jeśli żądanie się nie powiedzie.
2. Sprawdź wymagania dostawcy API dotyczące listy dozwolonych adresów IP
Aby ustalić, jak skonfigurować listę dozwolonych adresów IP dla API, zapoznaj się z dokumentacją konta API lub skontaktuj się z pomocą techniczną, by sprawdzić obowiązujące zasady. Przed skierowaniem ruchu produkcyjnego potwierdź wymagany format adresu, procedurę zatwierdzania i termin wprowadzenia zmian.
Ustal, jak dostawca stosuje reguły listy dozwolonych adresów do używanego konta i kluczy API. Jeśli konto ma kilka kluczy API, sprawdź, czy odpowiedni adres trzeba skonfigurować dla każdego z nich.
Zapytaj, czy podczas testów na liście może pozostać również obecny adres proxy rezydencyjnego. Pozostawienie obu dozwolonych adresów pozwala uniknąć wymuszonego przełączenia, zanim nowa trasa zostanie sprawdzona. Jeśli dostawca wymaga zgłoszenia zatwierdzającego lub okna serwisowego, uwzględnij to w planie, zamiast dowiadywać się o tym dopiero podczas wdrożenia.
W przypadku konta API z rygorystycznymi kontrolami dostępu porównaj adres oczekiwany przez dostawcę z adresem przypisanym do dedykowanego IP. Jeśli to możliwe, potwierdź adres za pomocą metody opisanej przez dostawcę lub bezpiecznego punktu testowego.
3. Dodaj dedykowany adres IP obok obecnego źródła
Gdy dostawca potwierdzi wymagany format i procedurę zatwierdzania, dodaj dedykowany adres IP do listy dozwolonych, nie usuwając obecnego źródła. Dzięki temu powstanie okno testowe, w którym można korzystać z obu tras. Zapisz szczegóły zmiany: dodany adres, konto lub klucz API, którego dotyczy, oraz status zatwierdzenia.
Przed przesłaniem zmiany sprawdź, czy adres został wpisany poprawnie. Literówka, niezamierzony zakres adresów lub wpis przypisany do niewłaściwego konta mogą utrudnić diagnozę: nowy klient może nadal otrzymywać błąd autoryzacji, mimo że lista dozwolonych adresów wygląda na zaktualizowaną. Jeśli procedura dostawcy na to pozwala, poproś drugą osobę o sprawdzenie adresu.
Jeśli dostawca API udostępnia oddzielne konta testowe i produkcyjne, sprawdź nowy wpis na koncie faktycznie używanym przez klienta. Pomyślny test w środowisku testowym nie potwierdza, że lista dozwolonych adresów na koncie produkcyjnym została zaktualizowana. Zapisz nazwy tych kont w notatkach dotyczących zmiany.
W przypadku samego połączenia proxy korzystaj z metody uwierzytelniania opisanej przez dostawcę i nie umieszczaj danych uwierzytelniających w kodzie źródłowym. Poradnik dobrych praktyk dotyczących uwierzytelniania proxy pomoże sprawdzić, w jaki sposób klient przekazuje dane logowania do proxy, nie myląc ich z danymi uwierzytelniającymi API.
4. Skieruj jednego klienta API przez dedykowany adres IP
Do pierwszego testu wybierz klienta o niskim poziomie ryzyka, na przykład workera w środowisku testowym, który wysyła reprezentatywne żądania, ale nie wprowadza zmian widocznych dla klientów. Zmień wyłącznie konfigurację ruchu wychodzącego tego klienta. Pozostaw bez zmian jego klucz API, nagłówki żądań, sposób tworzenia treści żądania i ustawienia limitu czasu, aby główną zmienną była trasa sieciowa.
Zadbaj o to, by nową trasę można było łatwo rozpoznać w konfiguracji. Możesz na przykład użyć zmiennej środowiskowej o jednoznacznej nazwie lub osobnej sekcji konfiguracji klienta, zamiast nadpisywać wspólne ustawienie proxy używane przez kilka aplikacji. Konkretne ustawienie zależy od środowiska uruchomieniowego i biblioteki klienta; przed wdrożeniem sprawdź, jak biblioteka obsługuje proxy i połączenia bezpośrednie.
Na czas testu pozostaw starą trasę dostępną. Wycofanie zmiany powinno polegać na przywróceniu poprzedniego ustawienia ruchu wychodzącego klienta, a nie na ponownym tworzeniu danych uwierzytelniających lub zmianie kodu żądań API. Nie zmieniaj danych uwierzytelniających.
Jeśli klient korzysta z proxy HTTP lub SOCKS5, aby połączyć się przez dedykowany adres IP, sprawdź protokół i port w instrukcjach dostawcy proxy. Różnice opisane w tym poradniku porównującym proxy SOCKS5 i HTTP mogą się przydać, gdy biblioteka klienta obsługuje jeden protokół, ale nie drugi. Przed wyborem sprawdź rzeczywiste wymagania biblioteki.
5. Przetestuj uwierzytelnianie API i podpisywanie żądań
Wyślij przez dedykowany adres IP niewielką liczbę reprezentatywnych żądań. Uwzględnij żądanie odczytu oraz — jeśli API umożliwia bezpieczne testowanie — żądanie wykorzystujące tę samą ścieżkę uwierzytelniania i podpisywania co klient produkcyjny. Pierwszy test przeprowadź na punkcie końcowym, który nie powoduje zmian; nie testuj, tworząc ani anulując prawdziwe zamówienie.
Zapisz kod odpowiedzi i treść błędu zwróconą przez dostawcę. Odpowiedź 401 lub 403 może wskazywać na problem z danymi uwierzytelniającymi, uprawnieniami albo regułą dotyczącą adresu IP, ale ostateczną wskazówką będzie odpowiedź dostawcy. Jeśli API korzysta z podpisanych żądań, porównaj metodę, ścieżkę, znacznik czasu, treść żądania i podpisane nagłówki przy obu trasach. Zmiana trasy sieciowej nie powinna wymagać nowego podpisu, ale edycja konfiguracji klienta może niechcący zmienić sposób tworzenia żądania.
Jeśli żądanie wysłane przez proxy rezydencyjne działa, a wysłane przez dedykowany adres IP kończy się niepowodzeniem, sprawdź listę dozwolonych adresów dla konta oraz uprawnienia przypisane do klucza. Zastosuj się do dokumentacji dostawcy dotyczącej reguł dostępu powiązanych z adresem IP.
Oddziel uwierzytelnianie proxy od uwierzytelniania API. Dane logowania do proxy uprawniają klienta do korzystania z proxy, a dane API uwierzytelniają żądanie kierowane do usługi. Log, który opisuje oba przypadki po prostu jako „błąd uwierzytelniania”, może niepotrzebnie wydłużyć diagnozę. Zapisuj wystarczająco dużo szczegółów, aby ustalić, na którym etapie połączenia lub obsługi żądania wystąpił błąd.
6. Sprawdź działanie API przy rzeczywistym obciążeniu
Jedno udane żądanie potwierdza podstawową łączność, ale nie gotowość do pracy produkcyjnej. Uruchom wybranego klienta z typowym wzorcem żądań i obserwuj kody odpowiedzi, opóźnienia, przekroczenia limitu czasu oraz ponawianie prób. Jeśli klient wysyła zarówno żądania odczytu, jak i zapisu, przetestuj oba rodzaje operacji, korzystając z bezpiecznych rekordów lub środowiska testowego zatwierdzonego przez dostawcę.
Zwróć uwagę na odpowiedzi informujące o przekroczeniu limitu zapytań. Sprawdź, jaki limit obowiązuje i jak jest naliczany — nie zakładaj, że dedykowany adres IP ma osobny limit. Porównaj sposób obsługi takiej odpowiedzi przez klienta z instrukcjami dostawcy, w tym z wymaganym czasem oczekiwania i nagłówkami odpowiedzi.
Zanim zwiększysz ruch, sprawdź mechanizm ponawiania prób i idempotencję. Jeśli żądanie przekroczy limit czasu po dotarciu do dostawcy, automatyczne ponowienie może powtórzyć operację zapisu, chyba że API obsługuje klucz idempotencji lub inną metodę zapobiegania duplikatom. Przetestuj ten mechanizm, używając takiego samego wzorca żądań jak podczas normalnej pracy klienta, i sprawdź, co API zwraca przy ponownym żądaniu.
Sprawdź też limity czasu połączenia i ponowne wykorzystywanie połączeń. Klient, który otwiera nowe połączenie dla każdego żądania, może zachowywać się inaczej niż klient utrzymujący połączenia, zwłaszcza gdy po drodze znajduje się proxy lub brama. Rejestruj osobno błędy zwracane przez samo API oraz błędy DNS, połączenia i proxy, aby zespół mógł ustalić, która warstwa wymaga uwagi.
7. Przełącz pozostałych klientów i wyłącz starą trasę
Gdy pierwszy klient pomyślnie przejdzie testy, przenoś kolejnych klientów pojedynczo. Aktualizuj po jednym środowisku lub serwisie, a następnie sprawdzaj, czy jego żądania korzystają z dedykowanego adresu IP i czy odsetek błędów związanych z API mieści się w normalnych granicach operacyjnych zespołu. Unikaj jednoczesnej zmiany globalnej — w takiej sytuacji trudniej ustalić źródło problemów.
Prowadź prosty rejestr zmian zawierający nazwę każdego klienta, czas wdrożenia, trasę i wynik testu. Jeśli któryś klient przestanie działać, rejestr pomoże odróżnić problem z jego konfiguracją od problemu z listą dozwolonych adresów po stronie dostawcy. Wstrzymaj wdrożenie do czasu ustalenia przyczyny, zamiast wprowadzać tę samą zmianę w kolejnych środowiskach.
Usuń adres proxy rezydencyjnego z listy dozwolonych dopiero wtedy, gdy potwierdzisz, że wszyscy wskazani klienci korzystają z dedykowanego adresu IP, a okres na wycofanie zmiany dobiegł końca. Sprawdź u dostawcy API, czy usunięcie wpisu wymaga zatwierdzenia lub zaczyna obowiązywać od razu. Po usunięciu starego adresu wyślij testowe żądanie z każdego przeniesionego środowiska.
Zachowaj konfigurację starej trasy w kontrolowanym rejestrze na potrzeby wycofania zmiany, ale bez uzasadnionej przyczyny nie pozostawiaj włączonego nieużywanego dostępu. Jeśli późniejsze wdrożenie będzie wymagało ponownego użycia proxy rezydencyjnego, przywróć dostęp zgodnie ze standardową procedurą zatwierdzania dostawcy, zamiast polegać na nieudokumentowanym wyjątku.