\u017beby skierowa\u0107 domen\u0119 na reverse proxy, podmieniasz w rekordzie A domeny (i w rekordzie AAAA, je\u015bli korzystasz z IPv6) adres IP serwera \u017ar\u00f3d\u0142owego na adres IP proxy. Od tej chwili proxy przekazuje ka\u017cde \u017c\u0105danie do Twojego serwera. Na papierze proste. Poni\u017cej: kt\u00f3re rekordy zmieni\u0107, dlaczego najpierw obni\u017cy\u0107 TTL, jak prze\u0142\u0105czy\u0107 si\u0119 bez przestoju i co sprawdzi\u0107 na koniec.<\/p>\n\n\n\n
Odwiedzaj\u0105cy i roboty wyszukiwarek dostaj\u0105 teraz dla domeny adres IP proxy, a proxy przekazuje ka\u017cde \u017c\u0105danie na adres IP serwera \u017ar\u00f3d\u0142owego, kt\u00f3rego nikt z zewn\u0105trz nie musi ju\u017c widzie\u0107. Szybko dwa poj\u0119cia. Serwer \u017ar\u00f3d\u0142owy<\/strong> (origin) to maszyna, na kt\u00f3rej faktycznie stoi strona. Reverse proxy<\/strong> to publiczne wej\u015bcie: najpierw przyjmuje ruch, a potem przekazuje go dalej.<\/p>\n\n\n\n Samo rozwi\u0105zywanie nazw jest nudne (i dobrze). Resolver odwiedzaj\u0105cego pyta autorytatywny serwer nazw o domen\u0119, dostaje rekord i trzyma go przez jaki\u015b czas w pami\u0119ci podr\u0119cznej. To cache’owanie jest wpisane w to, jak DNS rozwi\u0105zuje nazwy<\/a>. I w\u0142a\u015bnie dlatego zmiana DNS nigdy nie dociera wsz\u0119dzie jednocze\u015bnie.<\/p>\n\n\n\n Zwykle tylko rekord A dla domeny g\u0142\u00f3wnej i www, plus AAAA, je\u015bli domena ma IPv6. Ca\u0142a reszta zostaje bez zmian.<\/p>\n\n\n\n Na rekordzie AAAA ludzie najcz\u0119\u015bciej si\u0119 potykaj\u0105. Zapomnisz o starym, wskazuj\u0105cym na serwer \u017ar\u00f3d\u0142owy, i ka\u017cdy odwiedzaj\u0105cy przez IPv6 ominie proxy. Zaktualizuj go wi\u0119c albo usu\u0144, je\u015bli proxy nie ma adresu IPv6. Subdomeny typu mail., ftp. czy cpanel., kt\u00f3re nadal wskazuj\u0105 na serwer \u017ar\u00f3d\u0142owy, te\u017c zdradzaj\u0105 jego adres. Przejrzyj je po kolei i zdecyduj, co z ka\u017cd\u0105 zrobi\u0107.<\/p>\n\n\n\n Obni\u017c TTL rekord\u00f3w, kt\u00f3re zamierzasz zmieni\u0107, sporo przed prze\u0142\u0105czeniem, \u017ceby po aktualizacji resolvery szybko porzuci\u0142y stary adres IP. TTL (time to live) to czas, przez jaki resolver mo\u017ce trzyma\u0107 odpowied\u017a w pami\u0119ci podr\u0119cznej.<\/p>\n\n\n\n Najpierw sprawd\u017a, co masz teraz: Skonfiguruj i przetestuj proxy, zanim dotkniesz DNS, tak \u017ceby zmiana rekordu by\u0142a ostatnim krokiem, a nie pierwszym.<\/p>\n\n\n\n Przez ca\u0142y ten czas trzymaj serwer \u017ar\u00f3d\u0142owy w\u0142\u0105czony pod starym adresem. Ka\u017cdy, czyj resolver ma jeszcze ten adres w cache, nadal trafi na stron\u0119, zanim nowy rekord si\u0119 rozejdzie. Bez przerwy w dzia\u0142aniu i bez gniewnych maili.<\/p>\n\n\n\n Gdy proxy ju\u017c dzia\u0142a, dopu\u015b\u0107 na serwerze \u017ar\u00f3d\u0142owym HTTP i HTTPS tylko z adres\u00f3w IP proxy. Inaczej stary adres zostaje bocznym wej\u015bciem z pomini\u0119ciem proxy. Wystarczy jedna regu\u0142a firewalla na serwerze \u017ar\u00f3d\u0142owym.<\/p>\n\n\n\n Czy to wszystko? Nie do ko\u0144ca. Adres mo\u017ce nadal wyciec przez historyczne rekordy DNS, subdomeny wskazuj\u0105ce na serwer \u017ar\u00f3d\u0142owy i nag\u0142\u00f3wki maili wysy\u0142anych z tego serwera. Na w\u0142asnym NGINX-ie na serwerze \u017ar\u00f3d\u0142owym loguj prawdziwy adres IP klienta z nag\u0142\u00f3wka ustawianego przez proxy. I sprawd\u017a na prawdziwym \u017c\u0105daniu, kt\u00f3ry nag\u0142\u00f3wek faktycznie dociera, zamiast zgadywa\u0107 jego nazw\u0119 (tu ludzie myl\u0105 si\u0119 cz\u0119\u015bciej, ni\u017c mog\u0142oby si\u0119 wydawa\u0107).<\/p>\n\n\n\n Adresy IP widziane przez odwiedzaj\u0105cych i roboty te\u017c nios\u0105 w\u0142asne sygna\u0142y, wi\u0119c warto przyjrze\u0107 si\u0119 rekordom reverse DNS i PTR<\/a>. Zmieniasz adresy dla kilku domen naraz? Nasz poradnik o przenoszeniu stron na nowe IP<\/a> omawia stron\u0119 SEO.<\/p>\n\n\n\n Gotowe, gdy ka\u017cdy sprawdzany resolver zwraca IP proxy, strona odpowiada przez HTTPS za po\u015brednictwem proxy, a serwer \u017ar\u00f3d\u0142owy przyjmuje ruch wy\u0142\u0105cznie z proxy.<\/p>\n\n\n\nKt\u00f3re rekordy DNS trzeba zmieni\u0107?<\/h2>\n\n\n\n
\n
Obni\u017c TTL w DNS przed prze\u0142\u0105czeniem<\/h2>\n\n\n\n
dig example.com A<\/code>. Liczba obok rekordu to pozosta\u0142y TTL. Obni\u017c go w panelu DNS. Potem czekaj. Co najmniej tyle, ile wynosi\u0142 stary TTL, bo cache trzyma wcze\u015bniejsz\u0105 warto\u015b\u0107, dop\u00f3ki ta nie wyga\u015bnie. Gdy proxy dzia\u0142a ju\u017c bez niespodzianek, podnie\u015b TTL z powrotem, \u017ceby ograniczy\u0107 liczb\u0119 zapyta\u0144.<\/p>\n\n\n\nJak prze\u0142\u0105czy\u0107 DNS na proxy bez przestoju<\/h2>\n\n\n\n
\n
curl --resolve<\/code> albo wpis w pliku hosts przypisuj\u0105cy domen\u0119 do IP proxy.<\/li>\ndig @resolver example.com<\/code> i por\u00f3wnaj odpowiedzi.<\/li>\nJak ukry\u0107 adres IP serwera \u017ar\u00f3d\u0142owego?<\/h2>\n\n\n\n
Lista kontrolna po skierowaniu domeny na reverse proxy<\/h2>\n\n\n\n
\n