Przejdź do treści
SEO

Prawdziwe IP klienta za reverse proxy: jak zrobić to dobrze

Real Client IPs Behind a Reverse Proxy: Getting Them Right
W tym artykule
  1. Dlaczego serwer zapisuje adres proxy zamiast adresu odwiedzającego?
  2. X-Forwarded-For, X-Real-IP i nagłówek Forwarded: który przenosi IP klienta?
  3. Jak przywrócić prawdziwe IP klienta modułem nginx real_ip
  4. Zaufane adresy proxy: dlaczego ta lista decyduje o wszystkim
  5. PROXY protocol: wyjście, gdy nagłówki nie wystarczają
  6. Jak sprawdzić, czy prawdziwe IP klienta jest poprawnie logowane
  7. Podsumowanie
  8. FAQ

Żeby zobaczyć prawdziwe IP klienta za reverse proxy, potrzebujesz dwóch rzeczy. Proxy musi przekazać adres odwiedzającego w nagłówku żądania. A serwer docelowy musi przyjmować ten nagłówek tylko od zaufanych adresów proxy. Logi dostępu, analityka i weryfikacja crawlerów pokazują jeden adres proxy zamiast prawdziwych użytkowników i botów? W takim razie brakuje jednego z tych dwóch elementów. Poniżej: jak adres się gubi, które nagłówki go przenoszą, jak go przywrócić modułem nginx real_ip i jak sprawdzić, że poprawka naprawdę działa.

Dlaczego serwer zapisuje adres proxy zamiast adresu odwiedzającego?

Bo to proxy otwiera połączenie TCP z Twoim serwerem. Z definicji więc to proxy jest adresem zdalnym. Odwiedzający łączy się z proxy, a proxy nawiązuje zupełnie nowe połączenie z serwerem docelowym. W tym drugim połączeniu nic nie mówi, kto wysłał pierwotne żądanie, chyba że proxy to dopisze.

A skutki uboczne szybko się mnożą:

  • każdy wpis w logu dostępu ma ten sam adres IP,
  • weryfikacja botów przez reverse DNS nie przechodzi, bo proxy to nie Googlebot,
  • raporty geolokalizacji pokazują położenie proxy, a nie Twoich odbiorców,
  • reguły allow, deny i blokady per IP trafiają w proxy, a razem z nim we wszystkich.

Ten ostatni punkt boli najbardziej. Zablokujesz jeden uciążliwy adres i odetniesz całą publiczność.

W pracy nad SEO jest gorzej, niż się wydaje. Analiza logów serwera pod kątem problemów z crawlowaniem działa tylko wtedy, gdy wiesz, które żądania przyszły od prawdziwych crawlerów. Jeśli każda linia ma ten sam adres, co właściwie analizujesz? Poprawka dotyczy dwóch miejsc: proxy wysyła adres, a serwer docelowy decyduje, czy mu ufać.

X-Forwarded-For, X-Real-IP i nagłówek Forwarded: który przenosi IP klienta?

Każdy z nich może. Właściwy to po prostu ten, który Twoje proxy faktycznie wysyła. Różnią się formatem i popularnością:

  • Nagłówek X-Forwarded-For: lista adresów oddzielonych przecinkami, do której każde proxy dopisuje adres, od którego dostało żądanie. Pierwszy wpis od lewej to deklarowany pierwotny klient (zwróć uwagę na słowo „deklarowany”).
  • X-Real-IP: pojedynczy adres, bez łańcucha, zwykle ustawiany przez proxy NGINX.
  • Nagłówek Forwarded (RFC 7239): ustandaryzowana forma z parametrami for=, proto= i by=. W praktyce spotykany rzadziej.

Tu jest haczyk. Każdy klient może wysłać te nagłówki sam. Wartość jest więc tyle warta, ile proxy, które zapisało ostatni wpis. Nie zgaduj też, jaki nagłówek dodaje Twoje proxy. Zapytaj dostawcę, a potem obejrzyj surowe żądanie i sprawdź to sam.

Jak przywrócić prawdziwe IP klienta modułem nginx real_ip

Moduł nginx real_ip podmienia adres klienta na wartość z wybranego przez Ciebie nagłówka, a jeśli nagłówek zawiera port, podmienia też port. Wszystko to opisuje oficjalna dokumentacja modułu ngx_http_realip_module. Konfiguracja to pięć kroków:

  1. Sprawdź, czy moduł jest dostępny w Twojej kompilacji (nginx -V wypisuje wkompilowane moduły).
  2. Wpisz zakresy proxy w set_real_ip_from, jako pojedyncze adresy IPv4 lub IPv6 albo bloki CIDR.
  3. Wybierz nagłówek w real_ip_header.
  4. Włącz real_ip_recursive, gdy żądania przechodzą przez więcej niż jedno proxy.
  5. Przeładuj nginx i przetestuj.

Minimalny blok w kontekście http lub server wygląda tak. Przykładowe zakresy zamień na faktyczne adresy swojego proxy:

set_real_ip_from 192.168.1.0/24;
set_real_ip_from 2001:0db8::/32;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Gdy to zadziała, $remote_addr i log dostępu pokazują odwiedzającego. Logowanie i reguły allow/deny po prostu działają, bez żadnych innych zmian.

Zaufane adresy proxy: dlaczego ta lista decyduje o wszystkim

Nginx podmienia adres tylko wtedy, gdy połączenie przychodzi z jednego z zaufanych adresów proxy w set_real_ip_from. Ta lista to cała Twoja granica bezpieczeństwa. Naprawdę cała. Przy wyłączonym trybie rekurencyjnym nginx bierze ostatnią wartość z nagłówka. Przy włączonym bierze ostatni adres, którego nie ma na liście zaufanych, czyli pomija Twój własny łańcuch proxy.

Za szeroka lista (na przykład 0.0.0.0/0) i każdy może podrobić swoje IP sfałszowanym nagłówkiem. Za wąska i adres proxy zostaje w logach. Aktualizuj ją więc, gdy dostawca dodaje lub zmienia adresy wychodzące. Jeszcze jedno, o czym ludzie zapominają: zablokuj bezpośredni dostęp do serwera docelowego spoza zakresów proxy. Inaczej atakujący po prostu ominie proxy i wyśle sfałszowany nagłówek prosto na Twój serwer. I po zabawie.

PROXY protocol: wyjście, gdy nagłówki nie wystarczają

PROXY protocol przekazuje adres klienta na poziomie połączenia, a nie w HTTP. Przydaje się przy TCP albo TLS passthrough, gdzie proxy w ogóle nie widzi HTTP i nie może dodać nagłówków. W nginx włączasz proxy_protocol w dyrektywie listen, a potem ustawiasz real_ip_header proxy_protocol.

Obie strony muszą się jednak zgadzać. Listener, który oczekuje PROXY protocol, odrzuca zwykłe połączenia. Zwykły listener nie radzi sobie z dodatkowym nagłówkiem. Jeśli korzystasz z usługi NGINX reverse proxy Jalvo z adresami w UE i USA, cała ta konfiguracja odbywa się na Twoim własnym serwerze docelowym.

Jak sprawdzić, czy prawdziwe IP klienta jest poprawnie logowane

Prosty test: Twoja własna wizyta pojawia się w logu z Twoim prawdziwym adresem, a sfałszowany nagłówek wysłany prosto do serwera docelowego nic nie zmienia. Przejdź przez tę listę:

  • wejdź na stronę ze znanego IP i znajdź je w access.log,
  • wyślij sfałszowany X-Forwarded-For bezpośrednio do serwera docelowego i sprawdź, że został zignorowany,
  • sprawdź, czy adresy crawlerów w logu rozwiązują się przez reverse DNS,
  • porównaj dane geolokalizacji w analityce przed zmianą i po niej.

Na czas testów logowałbym $http_x_forwarded_for obok $remote_addr, żeby widzieć surowy łańcuch. Najczęstsze błędy? Pominięte zakresy IPv6. Literówka albo zła nazwa nagłówka. I dwie warstwy, na przykład CDN przed proxy, bez trybu rekurencyjnego. Jeśli dopiero wybierasz rozwiązanie, najpierw porównaj reverse proxy i VPN.

Podsumowanie

Przywrócenie prawdziwego IP klienta za reverse proxy sprowadza się do trzech rzeczy: proxy wysyła adres, serwer docelowy ufa tylko znanym zakresom proxy, a Ty testujesz wynik. W większości konfiguracji wystarczy moduł nginx real_ip z wąską listą set_real_ip_from i trybem rekurencyjnym. Chcesz więcej w tym temacie? Przejrzyj poradniki technicznego SEO o hostingu.

FAQ

Czy odwiedzający mogą podrobić swoje IP przez nagłówek X-Forwarded-For?

Tak, jeśli serwer docelowy ufa temu nagłówkowi od każdego. Ogranicz set_real_ip_from do zakresów swojego proxy i zablokuj bezpośredni dostęp do serwera docelowego, a problem znika.

Użyć X-Forwarded-For czy nagłówka Forwarded?

Tego, który Twoje proxy faktycznie wysyła. Forwarded, zdefiniowany w RFC 7239, jest standardem. Ale X-Forwarded-For ma znacznie szersze wsparcie w narzędziach i parserach logów.

Dlaczego po włączeniu real_ip logi nadal pokazują IP proxy?

Zwykle z jednego z trzech powodów: brakuje adresu łączącego się serwera w set_real_ip_from, nazwa nagłówka nie zgadza się z tym, co wysyła proxy, albo nginx nie został przeładowany. Żeby znaleźć przyczynę, loguj surowy nagłówek obok $remote_addr.

UdostępnijLinkedInX
Zespół Web Systems

Zespół, który tworzy i utrzymuje Jalvo.

Daj każdej stronie własne IP.

Pierwszą domenę dodasz w kilka minut.

Zacznij teraz

Wybierz, na które pliki cookie się zgadzasz. Niezbędne pliki cookie utrzymują działanie strony i logowania, nie można ich wyłączyć.