Cloudflare inställning för företagswebbplatser: hastighet och säkerhet, steg för steg

Cloudflare sitter mellan dina besökare och din server. Besökare ansluter till Cloudflare närliggande datacenter, som serverar cachade filer direkt, filtrerar fientlig trafik och vidarebefordrar resten till din server. För ett företag innebär det snabbare sidor för kunder långt från din värdplats, skydd mot enkla översvämningar av översvämningar av tjänster och en plats för att upprätthålla säkerhetsregler utan att ändra applikationskoden. Många planer börjar gratis, och betalplaner lägger till funktioner, så kontrollera den aktuella planjämförelsen innan du bestämmer dig.

Det är inte en ersättning för patchad programvara och säker kod. Vår PHP säkerhetschecklista gäller fortfarande. Tänk på Cloudflare som en stark ytterdörr, inte en ersättning för att låsa in rummen.

Innan du börjar

• Inventera din DNS. Exportera eller skärmbild varje post hos din nuvarande DNS-leverantör, inklusive post (MX, SPF, DKIM, DMARC) och verifieringsposter. Ett missat rekord är det klassiska sättet att bryta e-post under en migrering.
• Vet vem som äger domänregistrarkontot och se till att det är ett företagskonto med multifaktorautentisering. Du kommer att ändra namnservrar där.
• Sänk TTL för dina nyckelposter en dag i förväg om du kan, så att ändringar sprids snabbare.
• Välj en lugn tid och berätta för teamet. Planera en återställning: de gamla namnservrarna, nedskrivna.

Steg 1: lägg till webbplatsen och granska DNS

Lägg till din domän i Cloudflare instrumentpanel. Den skannar befintliga poster. Jämför dem med ditt lager och åtgärda luckor. Välj mellan två lägen för varje post:

• Proxied (orange moln): trafik går genom Cloudflare. Använd för din webbplats och webbapplikations värdnamn.
• Endast DNS (grå moln): Cloudflare svarar bara på DNS-frågan. Använd för e-postservrar, SSH- eller FTP-värdnamn och allt som inte är HTTP- eller HTTPS-trafik.

Uppdatera sedan namnservrarna hos din registrar. När webbplatsen visas som aktiv, kontrollera din webbplats och skicka ett testmejl.

Steg 2: ställ in kryptering korrekt

Det här är den inställning som bryter flest webbplatser. Cloudflare har flera SSL/TLS-lägen:

• Flexibel: krypterar besökare till Cloudflare men skickar trafik till din server okrypterad. Det ser ut som att det fungerar, men det andra benet är öppet, och det orsakar ofta omdirigeringsslingor. Undvik det.
• Full: krypterar båda benen men verifierar inte din servers certifikat.
• Fullständig (strikt): krypterar båda benen och verifierar certifikatet på din server. Det här är den som ska användas.

Installera ett giltigt certifikat på din server först. Ett Cloudflare Origin CA-certifikat eller ett gratis Let's Encrypt-certifikat fungerar båda. Byt sedan till Fullständig (strikt), slå på Använd alltid HTTPS, ställ in en minsta TLS-version på 1.2 och aktivera HSTS först efter att allt fungerar över HTTPS, eftersom HSTS säger åt webbläsare att vägra vanlig HTTP under en lång tid.

Steg 3: gör Cloudflare omöjlig att kringgå

Om angripare känner till din servers riktiga IP-adress kan de skicka trafik direkt till den och hoppa över alla skydd du har konfigurerat. Fixa detta på två sätt:

• Tillåt webbtrafik till din server endast från Cloudflare publicerade IP-intervall.
• Återställ den riktiga besökar-IP:n i din webbserver, eftersom annars varje begäran i dina loggar, hastighetsgränser och analyser verkar komma från Cloudflare.

#!/usr/bin/env bash
# /opt/cf/update_cloudflare_ips.sh - run weekly from cron
set -euo pipefail
IPS="$(curl -fsS https://www.cloudflare.com/ips-v4) $(curl -fsS https://www.cloudflare.com/ips-v6)"

# 1) real visitor IP for Nginx
OUT=/etc/nginx/conf.d/cloudflare_real_ip.conf
{
  for r in $IPS; do echo "set_real_ip_from $r;"; done
  echo "real_ip_header CF-Connecting-IP;"
} > "$OUT.tmp" && mv "$OUT.tmp" "$OUT"
nginx -t && nginx -s reload

# 2) firewall: allow HTTPS only from Cloudflare (remove any generic "allow 443" rule first)
for r in $IPS; do ufw allow proto tcp from "$r" to any port 443 comment 'cloudflare'; done

En viktig detalj för Docker-användare: portar publicerade av Docker går förbi ufw-regler. Bind behållare till localhost bakom en omvänd proxy, eller begränsa åtkomst i Docker DOCKER-USER brandväggskedja. För starkare isolering låter Cloudflare Tunnel din server endast göra en utgående anslutning, så den behöver inga öppna inkommande webbportar alls. För betalningswebbhooks och andra server-till-server-integrationer, se till att IP-reglerna fortfarande släpper igenom dessa förfrågningar om de inte går via Cloudflare.

Steg 4: cachningsregler

Som standard cachar Cloudflare statiska filer som bilder, CSS och JavaScript, men inte HTML. En vettig policy för en typisk PHP webbplats:

• Statiska tillgångar: cachelagret under lång tid (en månad eller mer). Använd versionsbaserade filnamn eller en frågesträng som app.css?v=123 så att en ny distribution hämtas omedelbart.
• Offentliga HTML-sidor (marknadsföringssidor, blogg): kan cachelagras i minuter till timmar med en Cache-regel. Testa noggrant.
• Cache aldrig: admin, konto, varukorg, kassa, API-slutpunkter och alla sidor som beror på en inloggningscookie. Skapa en förbikopplingsregel för dessa sökvägar och för förfrågningar som innehåller din sessionscookie.

Rensa automatiskt efter varje distribution så att kunder aldrig ser inaktuella filer. Skapa en API-token med endast behörigheten "Cache Purge" för den här zonen och anropa den från ditt distributionsskript:

# purge selected files after a deployment
curl -sS -X POST "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/purge_cache" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://example.com/css/app.css","https://example.com/js/app.js"]}'

Snabbare sidor hjälper också till med sökningar och omvandlingar. Se vår Core Web Vitals-guide för PHP webbplatser för vad som ska fixas på serversidan när CDN är på plats.

Steg 5: brandvägg, bots och hastighetsbegränsning

• Aktivera de hanterade WAF-reglerna som finns på din plan. De blockerar vanliga attackmönster innan de når din kod.
• Aktivera botskydd som passar din plan och titta på analysen innan du skärper något.
• Prisgränskänsliga slutpunkter: inloggning, lösenordsåterställning, registrering och utcheckning. Brute-force och korttestande attacker riktar sig mot exakt dessa.
• Undantag betrodd maskintrafik: betalningsleverantörens webhooks, övervakningstjänster och dina egna integrationer får inte drabbas av webbläsarutmaningar, eftersom en utmaningssida som returneras till en webhook ser ut som ett misslyckande.

# Custom rule 1: block probes for secrets and repositories (action: Block)
(http.request.uri.path contains "/.env" or http.request.uri.path contains "/.git" or http.request.uri.path contains "wp-config")

# Custom rule 2: let payment webhooks through (action: Skip, security features)
(http.request.uri.path in {"/webhooks/stripe" "/webhooks/paypal"})

# Rate limiting rule: at most 10 login attempts per minute per IP
(http.request.uri.path eq "/login" and http.request.method eq "POST")  =>  10 requests / 1 minute / IP

Regelsyntax och tillgängliga fält varierar beroende på plan, så behandla dessa som mallar och testa i "logg"-läge först. Behåll skydd på applikationsnivå också: kontroller av webhook-signaturer, som i vår Stripe webhooks-guide, beror aldrig enbart på nätverksregler.

Steg 6: verifiera installationen

# is traffic going through Cloudflare?
curl -sI https://example.com | grep -iE "^(server|cf-cache-status|cf-ray)"

# does the origin refuse direct access? (replace with your server IP; expect a timeout or refusal)
curl -sI --max-time 8 https://203.0.113.10 -H "Host: example.com" -k

# are the nameservers and mail records right?
dig NS example.com +short
dig MX example.com +short
dig TXT example.com +short

Kontrollera en statisk fil två gånger: det andra svaret ska visa cf-cache-status: HIT. Kontrollera inloggnings-, kassa- och adminflöden med en riktig webbläsare och skicka och ta emot ett testmail.

Vanliga misstag

• Flexibel SSL och omdirigeringsslingorna som följer.
• Proxy e-postvärdnamnet (det måste endast vara DNS) eller glömma en e-postpost under flytten.
• Cachar privata sidor så att en kund ser en annans kontosida. Gå alltid förbi cacheminnet för inloggad trafik.
• Lämnar ursprunget exponerat: den verkliga IP-adressen är synlig i gamla DNS-poster, e-postrubriker eller certifikatloggar. Begränsa brandväggen och överväg att ändra IP om den har läckt.
• Återställer inte den verkliga IP-adressen, vilket bryter mot hastighetsgränser, loggar och bedrägerikontroller.
• Utmanande webhooks och API:er, vilket orsakar tysta misslyckanden i betalningar och integrationer.
• Begärans storleksgränser: fullmaktsbegäranden har en maximal kroppsstorlek beroende på planen. Kontrollera den aktuella gränsen om din applikation accepterar stora uppladdningar.
• Glömma övervakning. Lägg till varningar för att certifikatet och domänen löper ut och kontrollera drifttiden, enligt beskrivningen i vår säkerhetskopierings- och övervakningsguide.

En checklista på en sida

1. DNS-inventering exporterat, registrarkonto säkrat.
2. Webbplats tillagd, poster granskade, fullmakt endast för webbhotellnamn.
3. Ursprungscertifikat installerat, SSL-läge Fullständigt (strikt), Använd alltid HTTPS på.
4. Brandvägg begränsad till Cloudflare intervall, riktiga besökares IP återställd.
5. Cacheregler för statiska tillgångar, bypass för privata sökvägar, rensa i distributionsskriptet.
6. Hanterade WAF på, prisgränser för inloggning och utcheckning, webbhooks undantagna.
7. Verifieringskommandon körs, varningar konfigureras, återställning dokumenteras.

Hur vi kan hjälpa till

Vi konfigurerar Cloudflare, hosting- och distributionspipelines för PHP applikationer och ansluter dem till betalnings-, CRM- och meddelandesystem. Läs om vår integrationstjänst eller boka ett kort samtal så granskar vi din DNS-, SSL- och cachinguppställning mot denna checklista.