Cloudflare a hosting IQhost — poprawna konfiguracja krok po kroku

Dla kogo: klienci, którzy chcą korzystać z Cloudflare (CDN, ochrona, DNS) przed swoim hostingiem w IQhost. Po co ten artykuł: źle skonfigurowany Cloudflare to najczęstsza przyczyna „nagle nie działa mi poczta / SSL / strona" po przejściu na CF. Ten poradnik pokazuje jedyną poprawną konfigurację — na realnym przykładzie ze zrzutami ekranu.

TL;DR — jedna zasada, którą musisz zapamiętać#

Rekordy pocztowe w Cloudflare MUSZĄ być ustawione na „DNS only" (szara chmurka), nie „Proxied" (pomarańczowa chmurka).

Cloudflare w trybie Proxy obsługuje wyłącznie ruch WWW (HTTP/HTTPS). Połączenia poczty (IMAP 993, POP3 995, SMTP 465/587 oraz SMTP 25 — poczta przychodząca między serwerami) i FTP (21) nie przechodzą przez proxy Cloudflare (przekazywanie dowolnych portów TCP jest dopiero w planie Enterprise). Rekord MX i port 25 nigdy nie są proxowane — serwer pocztowy musi być widoczny pod prawdziwym adresem. Jeśli zostawisz rekord mail na pomarańczowej chmurce, Twój program pocztowy (i inne serwery wysyłające do Ciebie) zamiast adresu serwera dostaną adres Cloudflare — i poczta przestanie działać.

Czego Cloudflare NIE zmienia — panel zawsze działa#

Panel DirectAdmin otwierasz zawsze przyciskiem „Otwórz panel" w Panelu Klienta (iqhost.pl). Prowadzi on do Twojej domeny technicznej w postaci hostXXXXX.iqhs.pl (na porcie 2222).

Ta domena należy do nas (iqhs.pl, nasze serwery nazw) i nigdy nie przechodzi przez Twój Cloudflare — niezależnie od tego, jak skonfigurujesz swoją domenę. Dlatego nawet przy błędnej konfiguracji CF panel zawsze jest dostępny, a Ty możesz wszystko poprawić. (Dodatkowo port 2222 i tak nie jest proxowany przez Cloudflare.)

Konfiguracja krok po kroku (na przykładzie domeny iqgr.pl)#

Krok 1 — Dodaj domenę w Cloudflare#

Po zalogowaniu do dash.cloudflare.com wybierz Add a domain, wpisz nazwę domeny i wybierz import DNS Automatic (Cloudflare sam zeskanuje istniejące rekordy z naszych serwerów nazw).

Krok 2 — Wybierz plan Free#

Do hostingu w zupełności wystarcza plan Free ($0): darmowy SSL, DNS, CDN i ochrona DDoS.

Krok 3 — ⚠️ NAJWAŻNIEJSZE: popraw chmurki przy rekordach poczty#

Cloudflare po zeskanowaniu domyślnie ustawia rekordy mail, pop, smtp, ftp, webmail, autoconfig, autodiscover na „Proxied" (pomarańczowa chmurka) — i to jest właśnie to, co psuje pocztę.

PRZED (źle) — rekordy poczty na pomarańczowej chmurce:

Kliknij chmurkę przy każdym rekordzie pocztowym, aby przełączyć ją na szarą „DNS only".

PO (dobrze) — poczta na szarej chmurce, tylko @ i www proxowane:

Krok 4 — Zmień serwery nazw u rejestratora#

Cloudflare przydzieli Ci dwa dedykowane serwery nazw (np. adrian.ns.cloudflare.com, austin.ns.cloudflare.com — każdy klient dostaje inną parę). Wpisz je u swojego rejestratora zamiast wszystkich naszych serwerów nazw (ns1.iqhs.eu, ns2.iqhs.eu, ns3.iqhs.eu) i zapisz. Cloudflare zastępuje całą naszą delegację swoją parą — nie zostawiaj obok żadnego z naszych nsX.iqhs.eu.

Zmiana delegacji domeny .pl propaguje się zwykle od kilkunastu minut do kilku godzin.

Ważne po zmianie NS: od tej chwili rekordy DNS edytujesz wyłącznie w panelu Cloudflare (DNS → Records). Strefa DNS w DirectAdmin przestaje być widoczna dla internetu. (Jeśli zostajesz na naszych NS — odwrotnie: rekordy edytujesz w DirectAdmin, nie w CF.)

Tabela: która chmurka przy którym rekordzie#

Pułapki, o których trzeba wiedzieć#

1. Cloudflare podmienia rekord MX na _dc-mx…#

Jeśli rekord mail zostanie na Proxy, Cloudflare automatycznie podmienia wartość MX na coś w rodzaju _dc-mx.xxxx.domena.pl (żeby ukryć origin). Skutek: poczta przychodząca przestaje docierać. Po przełączeniu rekordów poczty na „DNS only" MX wraca samoczynnie do mail.domena.pl — zawsze to potem sprawdź.

2. SPF / DKIM / DMARC — skopiuj DOKŁADNIE 1:1 z naszej strefy#

Przy imporcie strefy Cloudflare potrafi zgubić lub zmienić rekordy SPF, DKIM i DMARC. Zanim zmienisz NS, otwórz w DirectAdmin zarządzanie DNS i przepisz te rekordy 1:1 do Cloudflare.

• SPF — poprawny rekord dla hostingu IQhost wygląda np. tak:

  v=spf1 a mx ip4:195.117.36.226 ~all
  

  ⚠️ Nie podmieniaj IP „w ciemno". Jeśli musisz wpisać adres ręcznie, użyj IP serwera POCZTOWEGO (z którego wychodzi poczta — np. 195.117.36.226), a nie adresu A Twojej strony / IP dedykowanego konta (te bywają różne). Wpisanie IP strony zepsuje SPF. Dodatkowo, gdy domena główna jest na Proxy, mechanizm a w SPF rozwiązuje się na adresy Cloudflare — więc realną wysyłkę autoryzuje wyłącznie ten ip4: serwera pocztowego. Najbezpieczniej: skopiuj rekord dokładnie taki, jaki był w naszej strefie.
• DKIM — skopiuj rekord TXT selektora (np. default._domainkey) bez zmian.
• DMARC — skopiuj rekord _dmarc bez zmian.

Uwaga na SPF w rodzaju v=spf1 ~all (bez wskazania żadnego serwera): ~all to softfail — odbiorcy traktują Twoją pocztę jako niepożądaną i ląduje w spamie (twardy -all odrzuca ją całkowicie). Zawsze musi być wskazany serwer wysyłkowy (a mx ip4:…).

3. SSL/TLS w Cloudflare — ustaw Full (strict)#

W zakładce SSL/TLS → Overview wybierz tryb Full (strict). Tryb Flexible powoduje pętle przekierowań i błędy „too many redirects".

Certyfikaty per-nazwa (walidacja HTTP-01) odnawiają się automatycznie nawet przez proxy Cloudflare, więc origin ma ważny cert. Uwaga: certyfikat wildcard (walidacja DNS-01) przy NS na Cloudflare NIE odnawia się automatycznie (patrz sekcja Wildcard). Tryb Full (strict) wymaga, aby każda proxowana nazwa hosta miała na originie ważny certyfikat — proxowana subdomena bez własnego certu zwróci błąd 525/526.

4. Ostrzeżenie „Your origin IP is partially exposed" — zignoruj#

Po przełączeniu rekordów poczty na „DNS only" Cloudflare pokaże ostrzeżenie o częściowo odsłoniętym IP. Dla poczty jest to normalne i nieuniknione — serwer pocztowy musi być widoczny pod prawdziwym adresem, inaczej poczta nie ma jak działać.

Wildcard SSL (*.domena) a Cloudflare — ważne ograniczenie#

Jeśli Twoja domena ma serwery nazw Cloudflare, nasz system NIE wystawi automatycznie certyfikatu wildcard (*.domena) — nawet z tokenami API Cloudflare.

Dlaczego (dokładny mechanizm): certyfikat wildcard można potwierdzić wyłącznie metodą DNS-01 (rekord TXT _acme-challenge). Nasz mechanizm (DirectAdmin + klient ACME „lego") domyślnie zapisuje ten rekord w lokalnej strefie DNS na serwerze i lokalnie go potwierdza — bo serwer hostuje autorytatywną strefę domeny. Problem: gdy domena jest delegowana do Cloudflare, publiczne autorytatywne serwery nazw to Cloudflare, które tego rekordu nie mają. Let's Encrypt idzie za delegacją do Cloudflare i wpisu nie znajduje → weryfikacja pada. Token API Cloudflare tego nie naprawia: zapisuje rekord po stronie Cloudflare, ale lokalny pre-check „lego" i tak czyta lokalną strefę i go nie widzi.

To domyślne zachowanie zależy od tego, że serwer hostuje lokalną strefę domeny; jego zmiana wymaga ingerencji administratora (np. wyłączenia lokalnej strefy DNS domeny na serwerze) i wykonujemy ją indywidualnie.

Potwierdzone w praktyce:

• ✅ Wildcard działa, gdy NS są u nas (ns1/ns2/ns3.iqhs.eu) — test na żywo *.iqgr.pl: Validations succeeded; Certificate for *.iqgr.pl,iqgr.pl has been created successfully!
• ❌ Wildcard nie działa, gdy NS są na Cloudflare — udokumentowane na realnym przypadku klienta (log: „niepowodzenie odczytu TXT… szuka na naszych DNS-ach").

Twoje opcje, jeśli zależy Ci na SSL:

1. Zostaw/przenieś NS do nas (ns1/ns2/ns3.iqhs.eu) → wildcard i wszystkie certy odnawiają się automatycznie. Wtedy jednak rezygnujesz z proxy/CDN Cloudflare — na planie Free proxy CF działa wyłącznie, gdy domena używa serwerów nazw Cloudflare (tryb „NS gdzie indziej + proxy CF" jest dopiero w planach Business/Enterprise).
2. Zostań przy Cloudflare, ale zrezygnuj z wildcarda → używaj certów per-nazwa (domena, www, mail, …). Weryfikowane metodą HTTP-01, działają przez proxy CF, pokrywają stronę i pocztę, odnawiają się same — bez tokenów i bez zmiany NS. Dla większości klientów to w zupełności wystarcza.
3. Certyfikat brzegowy Cloudflare (Universal SSL) — CF sam obsługuje SSL między odwiedzającym a swoją siecią. Na planie Free pokrywa domenę i subdomeny jednego poziomu (*.domena); subdomeny wielopoziomowe (a.b.domena) wymagają płatnego Advanced Certificate Manager. Pamiętaj też, że: (a) nie obejmuje to poczty (porty pocztowe nie idą przez CF), (b) przy trybie Full (strict) origin i tak musi mieć własny certyfikat dla każdej proxowanej nazwy — brzegowy cert CF go nie zastępuje.

Panel DirectAdmin — zawsze przez domenę techniczną#

Do zarządzania hostingiem (DirectAdmin) nie używaj swojej domeny — wchodź przez Panel Klienta → „Otwórz panel", który loguje Cię automatycznie na hostXXXXX.iqhs.pl:2222. Ta ścieżka nigdy nie przechodzi przez Cloudflare, więc działa zawsze, niezależnie od konfiguracji Twojej domeny.

Szybka diagnostyka: objaw → przyczyna → rozwiązanie#

FAQ#

Czy muszę używać Cloudflare? Nie. Nasza infrastruktura ma własną ochronę (WAF, anty-DDoS, Imunify360). Cloudflare to opcja, jeśli chcesz dodatkowego CDN/cache.

Czy Cloudflare przyspieszy pocztę? Nie — poczta w ogóle nie przechodzi przez Cloudflare (i nie powinna). CF przyspiesza wyłącznie ruch WWW.

Mam wiele subdomen — potrzebuję wildcarda. Wtedy najwygodniej przenieść NS do nas (ns1/ns2/ns3.iqhs.eu) — wildcard odnawia się automatycznie (rezygnujesz wówczas z proxy CF). Cloudflare przy NS=CF wildcarda nie obsłuży (patrz wyżej).

Zmieniłem chmurki, a poczta dalej nie działa. Odczekaj kilka–kilkanaście minut na propagację DNS i sprawdź, czy MX wskazuje mail.domena (nie _dc-mx…). Jeśli problem trwa — napisz do nas, sprawdzimy logi.

W razie wątpliwości napisz zgłoszenie w Panelu Klienta — pomożemy dobrać konfigurację.