Cloudflare: DNS, cache i origin bez zgadywania

DNS nie wybiera aplikacji za serwer

Rekord A lub CNAME pomaga skierować ruch, ale serwer HTTP nadal musi obsługiwać żądaną nazwę hosta. CNAME do działającej domeny nie kopiuje automatycznie jej ustawień reverse proxy. Gdy Cloudflare pośredniczy w ruchu, publiczny DNS zwykle pokazuje adresy Cloudflare, a nie bezpośredni adres originu.

Zapisz odpowiedź, zanim wyczyścisz cache

curl -sS -D - -o /dev/null https://example.com/
curl -sS -D - -o /dev/null https://example.com/assets/app.v2.js

Porównaj kod HTTP, Content-Type, Cache-Control i CF-Cache-Status. Nagłówek Age, jeśli występuje, pomaga ocenić wiek zapisanej odpowiedzi. Nie utożsamiaj MISS z błędem: może oznaczać pobranie zasobu z originu zamiast z cache.

Porównaj z originem

Administrator może sprawdzić lokalny serwer z właściwym nagłówkiem Host. To test routingu HTTP na originie, nie dowód poprawności publicznego TLS. Nie udostępniaj prywatnego originu tylko w celu wykonania tego porównania.

curl -sS -I -H "Host: example.com" http://127.0.0.1/

Jeśli origin odpowiada poprawnie, a publiczny adres zwraca 404 od innego pośrednika, sprawdź konfigurację tej warstwy. Jeżeli oba zwracają ten sam błąd, diagnozuj aplikację lub pliki. Zapisz wyniki dla tego samego hosta i tej samej ścieżki.

Wersjonuj zasoby, nie daty treści

Dla zmienionego JavaScriptu lub CSS używaj nowej nazwy pliku albo kontrolowanego identyfikatora wersji. Nowy parametr nie zawsze ominie cache, jeśli reguły ignorują query string. Otwarta karta może wciąż wykonywać wcześniej pobrany kod nawet wtedy, gdy serwer podaje już nowy. Pełne odświeżenie testuje nowy dokument; nie powinno być jednak stałym zamiennikiem poprawnego wdrożenia.

• Purge wykonuj dla konkretnego zasobu, gdy to wystarczy.
• Nie wyłączaj globalnie cache, żeby naprawić pojedynczy plik.
• Konto, koszyk i dane prywatne wymagają osobnej polityki buforowania.

Czytaj dalej