Amazon CloudFront er et sikkert og programmerbart content delivery network. Når du har lanceret dit websted på Kinsta, hvis du gerne vil bruge Amazon CloudFront i stedet for Kinstas CDN, viser denne guide dig hvordan.

Nogle af sikkerhedsfunktionerne i CloudFront inkluderer kryptering på feltniveau og beskyttelse mod netværk og applikationslag DDoS-angreb.

Anmod om brugerdefineret SSL-certifikat

En del af din Cloudfront-distributionsopsætning inkluderer anvendelse af et brugerdefineret SSL-certifikat. Da dette kan tage alt fra et par minutter til flere timer at fuldføre, anbefaler vi, at du anmoder om det tilpassede SSL-certifikat, før du starter processen med at oprette en ny distribution.

Hvis du ikke allerede har en AWS-konto, kan du oprette en her. Når du er logget ind på din AWS-konto, søg efter “Certificate administrator ” ved hjælp af søgefeltet i menulinjen og klik på Certificate administrator  under Services.

Klik på Certifikatadministrator under Services i din CloudFront-konto.
Klik på Certifikatadministrator under Services i din CloudFront-konto.

I Certificate administrator skal du klikke på knappen Request Certificate.

Klik på knappen Anmod om et certifikat i AWS Certificate administrator.
Klik på knappen Anmod om et certifikat i AWS Certificate administrator.

På næste side skal du vælge Anmod om et offentligt certifikat og klikke på knappen Anmod om et certifikat.

Vælg Anmod om et offentligt certifikat, og klik på knappen Anmod om et certifikat
Vælg Anmod om et offentligt certifikat, og klik på knappen Anmod om et certifikat

Tilføj domænenavne

I formularen Anmod om et certifikat skal du tilføje dit brugerdefinerede domæne (dit websteds primære domæne på Kinsta) til domænenavnelisten (hvis du tilføjer et roddomæne, skal du sørge for at tilføje både ikke-www- og www-domænet eller tilføje jokertegnet domæne som *.example.com), og klik på Next.

Tilføj dit brugerdefinerede domæne til anmodningen om SSL-certifikat i AWS Certificate Manager.
Tilføj dit brugerdefinerede domæne til anmodningen om SSL-certifikat i AWS Certificate Manager.

Domænevalidering

På den næste skærm vælger du enten e-mail- eller DNS-validering for dit SSL-certifikat. Vælg den mulighed, der fungerer bedst for dig.

Hvis din domæneregistrering ikke har privatlivsbeskyttelse, der skjuler dine kontaktoplysninger fra WHOIS-opslag, eller hvis e-mail sendt til proxy-e-mailadressen videresendes til din rigtige e-mailadresse, kan du bruge e-mail-valideringsmetoden til at validere din certifikatanmodning.

Hvis du ikke er i stand til at modtage e-mails på den e-mailadresse, der vises i WHOIS-opslag, skal du bruge DNS-valideringsmetoden.

E-mail validering

Vælg e-mail-validering, og klik på knappen Next for at starte e-mail-valideringen.

Start e-mail-validering for AWS SSL-certifikat.
Start e-mail-validering for AWS SSL-certifikat.

Du modtager op til 8 e-mails for hvert domæne, du føjede til certifikatet, og du skal reagere på mindst én e-mail for hvert domæne for at fuldføre valideringen.

DNS-validering

For at bruge denne metode skal du vælge DNS-valideringsmetoden og klikke på knappen Next.

Amazon Certificate Manager DNS-validering for SSL-certifikat.
Amazon Certificate Manager DNS-validering for SSL-certifikat.

På siden Tilføj tags er du velkommen til at tilføje nogle valgfri tags, hvis det er nødvendigt, og klik på Gennemse for at fortsætte til næste trin.

Gennemgå anmodning om SSL-certifikat.
Gennemgå anmodning om SSL-certifikat.

På siden Gennemse skal du klikke på knappen Bekræft og anmod for at fortsætte til valideringstrinnet.

Bekræft anmodning om SSL-certifikat.
Bekræft anmodning om SSL-certifikat.

På næste side skal du klikke på pileikonet ud for dit brugerdefinerede domænenavn for at se CNAME-detaljerne til validering. Du skal oprette en CNAME-record for dit tilpassede domæne med disse detaljer.

CNAME-record oplysninger til domænevalidering.
CNAME-record oplysninger til domænevalidering.

For at tilføje denne nye CNAME-record skal du logge ind, hvor du administrerer dit domænes DNS. For dette eksempel viser vi dig, hvordan du tilføjer CNAME-record i Kinsta’s DNS. Hvis du har en anden DNS-udbyder (kan være din registrator eller en anden DNS-host, afhængigt af hvor du har peget på dit domænes navneservere), kan trinene være lidt anderledes.

  1. Klik på DNS i venstre sidebar navigation i MyKinsta.
  2. Klik på linket Administrer for det domæne, du vil tilføje en DNS-record til.
  3. Klik på knappen Add a DNS-record.
  4. Klik på fanen CNAME, og tilføj hostnavnet (alt før dit brugerdefinerede domæne i feltet Navn fra CloudFront) og peger på (Værdi fra CloudFront). Klik på knappen Add DNS-record for at gemme din nye CNAME-record.

Bemærk: Afhængigt af dine DNS-records TTL-indstilling kan det tage alt fra et par minutter til timer, før en DNS-record udbredes.

Tilføj en CNAME-record til AWS SSL-validering.
Tilføj en CNAME-record til AWS SSL-validering.

Gå tilbage til CloudFront-valideringssiden, og klik på Continue.

Fortsæt DNS-validering.
Fortsæt DNS-validering.

Når en CNAME-record udbredes og er blevet valideret, ændres SSL-certifikatets status fra Pending til Issued.

SSL-certifikat udstedt i Amazon Certificate Manager.
SSL-certifikat udstedt i Amazon Certificate Manager.

Dit nye SSL-certifikat er klar til at blive brugt med din nye CloudFront-distribution, og du kan begynde at konfigurere det nu.

Konfigurer og implementer CloudFront Zone

Det næste trin er at konfigurere og implementere en CloudFront-zone. I din AWS-konto, søg efter “CloudFront” ved hjælp af søgefeltet i menulinjen, og klik på CloudFront under Services.

Vælg CloudFront under Services i AWS.
Vælg CloudFront under Services i AWS.

Klik derefter på Create a CloudFront distribution.

Opret en CloudFront-distribution.
Opret en CloudFront-distribution.

Du kan konfigurere detaljerne for en ny CloudFront-zone på siden Opret distribution. Vi anbefaler konfigurationen nedenfor for maksimal kompatibilitet med Kinstas Cloudflare-integration.

Oprindelse

Anbefalede origin indstillinger:

  • origin domain: Dit websteds kinsta.cloud-domæne (i vores eksempel her: myawewsomesite.kinsta.cloud). CloudFront accepterer ikke en IP-adresse som oprindelse, så du skal bruge dit websteds kinsta.cloud-domæne i dette felt.
  • Følgende 3 felter vises, når du indtaster dit oprindelsesdomæne:
    • Protocol: Kun HTTPS
    • HTTPS-port: 443
    • Minimum Origin SSL-protocol: TLSv1
  • Origin path: Lad dette stå tomt.
  • Name (valgfrit): Du kan indtaste et brugerdefineret navn for oprindelsen her, men det er ikke påkrævet.
  • Archive Origin Shield: No.
Anbefalede oprindelsesindstillinger for CloudFront-distribution.
Anbefalede oprindelsesindstillinger for CloudFront-distribution.

Default cache behavior

Mens du konfigurerer indstillingerne for cache behavior, skal du oprette to CloudFront-politikker: cache policy og origin request policy, som vi har skitseret for dig nedenfor.

Anbefalede indstillinger for afsnittet Default Cache Behavior:

  • Stimønster: Standard.
  • Komprimer objekter automatisk: Yes.
  • Viewer Protocol Policy: Omdiriger HTTP til HTTPS.
  • Tilladte HTTP-metoder: GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE.
  • Begræns seeradgang: No.
  • Cachenøgle og oprindelsesanmodninger: Cachepolitik og oprindelsesorigin request policy.
    • Cache Politik: Vælg din nye brugerdefinerede cache policy (se trin til oprettelse nedenfor).
    • Oprindelses Anmodninspolitik: Vælg din nye tilpassede oprindelses origin request policy (se trin til oprettelse nedenfor).
Anbefalede cache-adfærdsindstillinger for CloudFront-distribution.
Anbefalede cache-adfærdsindstillinger for CloudFront-distribution.

Sådan opretter du en CloudFront Cache policy

Klik på Opret politik i afsnittet Cache policy. Dette vil starte siden for oprettelse af en cache policy i en ny fane i din browser.

Opret en cache policy i CloudFront.
Opret en cache policy i CloudFront.

Angiv et navn (f.eks. KinstaCachePolicy) for cache plicy i afsnittet Details.

I afsnittet TTL-settings skal du bruge følgende indstillinger:

  • Minimum TTL: 0
  • Maximum TTL: 31536000
  • Default TTL: 86400

I afsnittet Cache key settings skal du bruge følgende indstillinger:

  • Headers: None
  • Query Strings: All
  • Cookies: All

Marker Gzip og Brotli i sektionen Compression support, og tryk derefter på knappen Create.

Anbefalede cache policy indstillinger i CloudFront.
Anbefalede cache policy indstillinger i CloudFront.

Luk denne browserfane og vend tilbage til den fane, hvor du opretter din nye CloudFront-distribution.

Klik på opdateringsknappen ved siden af rullemenuen cache policy, og vælg din nye tilpassede cache politik i rullemenuen.

Vælg din tilpassede cache politik.
Vælg din tilpassede cache politik.

Sådan opretter du en CloudFront origin request policy

Klik på Opret politik i afsnittet Oprindelses origin request policy. Dette vil starte siden Create origin request policy på en ny fane i din browser.

Opret en Origin request policy i CloudFront.
Opret en Origin request policy i CloudFront.

Angiv et navn (f.eks. KinstaOriginPolicy) for Origin request policy  i afsnittet Details.

I afsnittet Indstillinger for Origin request  skal du vælge følgende:

  • Headers: All viewer headers
  • Query Strings: All
  • Cookies: All

Klik på knappen Create for at færdiggøre request policy.

CloudFront Origin-request policy indstillinger.
CloudFront Origin-request policy indstillinger.

Luk denne browserfane og vend tilbage til den fane, hvor du opretter din nye CloudFront-distribution.

Klik på opdateringsknappen ud for rullemenuen origin request policy, og vælg din nye tilpassede politik for anmodning om oprindelse i rullemenuen.

Vælg din custom origin request policy i Origin request policy.
Vælg din custom origin request policy i Origin request policy.

Function Associations

Vi anbefaler ikke at indstille nogen Function Associations. Disse lader dig tildele AWS Lambda-serverløse funktioner til forskellige triggere inden for anmodningens livscyklus (f.eks. seeranmodning, seersvar, origin request osv.).

Selvom det er muligt at bruge function associations sammen med Kinstas CDN, kan der være nogle scenarier, hvor en Lambda-funktion kan være i konflikt med Kinstas CDN. Hvis du gerne vil bruge tilpassede Lambda-funktioner på dit websted, anbefaler vi, at du samarbejder med en udvikler for at fejlfinde problemer, hvis de dukker op.

Settings

Anbefalet konfiguration for afsnittet Settings:

  • Price Class: Vælg de CloudFront-regioner, du gerne vil bruge med dit websted.
  • AWS WAF Web ACL: Hvis du har brug for at oprette en ACL med brugerdefinerede firewall-regler, anbefaler vi at arbejde med en AWS-ekspert for at undgå konflikter med Kinstas CDN.
  • Alternate Domain Name: Klik Add item, og angiv det tilpassede domæne (dit websteds primære domæne hos Kinsta).
  • Custom SSL Certificate: Vælg det brugerdefinerede SSL-certifikat, du oprettede i begyndelsen af ​​denne øvelse.
  • Du vil se et par ekstra muligheder efter at have valgt det brugerdefinerede SSL-certifikat:
    • Legacy clients support:: Lad dette være umarkeret/deaktiveret.
    • Security Policy: TLSv1.2_2021
  • Supported HTTP Versions: HTTP/2
  • Standard logging: Off
  • IPv6: On
Gem distributions indstillinger for at oprette din nye CloudFront-zone.
Gem distributions indstillinger for at oprette din nye CloudFront-zone.

Klik på knappen Create distribution for at afslutte oprettelsen af ​​din nye CloudFront-zone.

Fejlfinding af almindelige CloudFront-problemer

502 fejl

Hvis du ser 502-fejl på dit websted efter oprettelse af din CloudFront-distribution, skal du dobbelttjekke Origin Domain i dine Origin Settings. Dette skal være dit websteds kinsta.cloud-domæne, ikke dit live-domæne.

Ændringer vises ikke på dit websted

Indstilling af dit websted til at bruge CloudFront skaber et ekstra lag af cache, som skal ryddes, når som helst du skal rydde cachen. Hvis du har problemer med at se ændringer på dit websted, eller et plugin ikke opfører sig som forventet efter installation eller geninstallation, skal du sørge for at rydde cache på alle lag, inklusive:

  1. Plugins (hvis relevant)
  2. Temaer (hvis relevant)
  3. Site/server cache hos Kinsta (fra enten MyKinsta eller Kinsta MU plugin)
  4. Cache på CloudFront (Gør dette ved at ugyldiggøre objekter. Brug /* til object path, der skal ugyldiggøres, vil rydde al cache.)
  5. Browser cache

IP-adresse blokeret af falsk positiv

Hvis du har DDoS-reduktion eller bot-detektion aktiveret på CloudFront, og du eller en besøgende på et websted fejlagtigt bliver blokeret fra at se dit websted, kan det skyldes en falsk positiv. Hvis dette sker, skal du arbejde med både AWS-support og Kinsta Support for at finde ud af, hvor blokeringen sker.

HTTP-HTTPS Redirect Loops

Hvis der opstår nogen HTTP til HTTPS Redirect Loops, skal du sørge for, at protokollen er indstillet til Kun HTTPS i dine CloudFront Origin-indstillinger for dit domæne.

IP Geolocation-omdirigeringer fungerer ikke korrekt

Page Cache, som er aktiveret som standard på CloudFront, kan forstyrre enhver IP Geolocation-omdirigering, du indstiller på Kinsta. Hvis dette sker, skal du deaktivere cachelagring på CloudFront eller konfigurere din cache politik til kun at cache de filer, der ikke er specifikke for en placering. Hvis du støder på problemer med at konfigurere det, anbefaler vi, at du samarbejder med en udvikler for at konfigurere din tilpassede cache politik.

Kan ikke logge ind på WordPress Dashboard

Login fungerer ikke uden POST-understøttelse. Anden funktionalitet på hjemmesiden kan også blive påvirket. Sørg for, at de Allowed HTTP methods under Default cache behavior er indstillet til GET, HEAD, OPTIONS, PUT, POST, PATCH, og DELETE.

Avancerede indstillinger og kompatibilitet

Begræns seeradgang med signerede URL’er og signerede cookies

Nogle muligheder, såsom begrænsning af adgang til filer på brugerdefinerede origins, fungerer muligvis ikke, fordi Cloudflare altid cacher statiske anmodninger.