En omvänd proxy kan användas för att ladda en WordPress-webbplats från en underkatalog medan en helt separat webbplats laddas på rotdomänen.

En omvänd proxy består av en uppsättning regler som läggs till en webbserver som instruerar servern att skicka förfrågningar om en viss underkatalog till en separat server.

Låt oss överväga ett exempel för att bättre förstå vad en omvänd proxy kan användas för. Tänk dig att du har en icke-WordPress-webbplats som laddar på example.com och du vill använda WordPress för att driva en blogg. Du vill att bloggen ska ladda på example.com/blog och du vill hosta din blogg hos en hanterad WordPress-värd som Kinsta.

För att fixa detta behöver omvänd proxy-regler konfigureras på webbservern som hostar example.com, och instruera webbservern att skicka eventuella förfrågningar om /blog-underkatalogen till en annan webbserver som hostar den WordPress-drivna /blog-webbplatsen.

Omvänd Proxy-tillägg

Kinsta tillåter och stöder användningen av omvända proxies för att ladda WordPress från en underkatalog eller för att rikta en underkatalog till din webbplats till en extern server. Omvända proxies är dock ofta utmanande att konfigurera och stödja, och webbplatser som använder sig av omvända proxies kräver vanligtvis betydligt mer stöd än vanliga WordPress-installationer.

Av denna anledning tillämpas en $50 månatlig tilläggsprenumeration för varje omvänd proxy som Kinsta hjälper till att konfigurera eller ger support för.

Dessutom kan du behöva tillåta upp till en hel arbetsdag för första installationen av en omvänd proxy. I vissa fall kan ytterligare tid och samarbete med Kinstas supportteam behövas för att få den omvända proxyn att fungera korrekt i mer ovanliga användningsfall.

Användningsfall för en omvänd proxy

Det finns tre möjliga användningsfall för omvända proxies här på Kinsta. För att förstå dessa användningsfall måste vi först definiera två termer: huvudwebbplats och proxywebbplats

  • Huvudwebbplatsen är den webbplats som laddar på rotdomänen.
  • Proxywebbplatsen är den webbplats som laddar från en underkatalog över en omvänd proxy.

Om vi går tillbaka till vårt exempel ovan, skulle example.com vara huvudwebbplatsen medan example.com/blog skulle vara proxywebbplats.

Med dessa definitioner i åtanke, är dessa de tre möjliga användningsfallen för omvända proxies på Kinsta:

  • Huvud- och proxywebbplatser hostas båda hos Kinsta: Huvudwebbplatsen example.com, och proxywebbplatsen, example.com/blog, är båda hostade hos Kinsta. Detta skulle låta en WordPress-installation driva example.com medan en helt separat WordPress-installation användes på example.com/blog.
  • Proxywebbplats hostas av Kinsta: Huvudwebbplatsen, example.com, är inte hostad hos Kinsta medan proxywebbplatsen, example.com/blog är hostad hos Kinsta. Detta skulle göra det möjligt för en WordPress-installation som hostas på Kinsta att användas på example.com/blog, medan huvudwebbplatsen hostas någon annanstans.
  • Huvudwebbplats hostas av Kinsta: Huvudwebbplatsen, example.com, är hostad hos Kinsta medan proxywebbplatsen, example.com/blog inte är hostad hos Kinsta. Detta skulle göra det möjligt för en WordPress-installation som hostas på Kinsta att användas på example.com, medan blogg-underkatalogen är hostad någon annanstans.

Låt oss granska konsekvenserna av varje alternativ, i synnerhet täcker vi gränserna för Kinstas support för varje scenario.

Omvänd proxyserver exempel

Omvänd proxyserver exempel

Huvud- och proxywebbplatser hostas båda hos Kinsta

Om båda webbplatserna är hostade hos Kinsta kan Kinstas supportteam ställa in de nödvändiga omvänd proxy-reglerna på huvudwebbplatsen och även konfigurera proxywebbplatsen att ladda över omvänd proxy. Observera att både huvudwebbplatsen och proxywebbplatsen måste vara placerade hos samma datacenter. Vidare är ett kortare driftstopp möjligt under installationen av en omvänd proxy när Kinsta får webbplatserna på plats.

I detta scenario skulle kundens ansvar omfatta följande:

  • Migrera båda webbplatserna till Kinstas miljö (eller skicka migreringsförfrågningar för att Kinsta ska migrera webbplatserna åt dig).
  • Öppna ett supportärende och förse Kinsta’s support team med en klar beskrivning över domän-konfigurationen. Vänligen notera att endast användare med faktura-behörighet (företagsägare, företagsadmin, ekonomiavdelning) kan efterfråga tillägget (add-on).
  • Du kan behöva vänta en arbetsdag för varje omvänd proxy-installation.

I detta scenario skulle Kinstas ansvar omfatta följande:

  • Konfigurera de nödvändiga omvänd proxy-reglerna på huvudwebbplatsen.

Konfigurera proxywebbplatsen att ladda över omvänd proxy.

Endast Proxywebbplats hostas hos Kinsta

Viktigt: Om endast proxywebbplatsen är hostad på Kinsta kräver vi att du ger oss proxyserverns IP-adresser och konfigurerar proxyservern för att ställa in rubrikerna som anges i vår standard omvänd proxy-regel för Nginx. Dessa steg krävs för att säkerställa att vårt analyssystem fungerar korrekt och att vi inte svartlistar din proxyservers IP-adresser. 

Om bara proxywebbplatsen är hostad hos Kinsta är konfiguration av själva den omvända proxyn inte något Kinsta kommer att kunna göra eftersom en omvänd proxy måste konfigureras på servern som är värd för huvudwebbplatsen. I detta scenario är Kinstas ansvar begränsat till att konfigurera proxywebbplatsen så att den är redo att laddas över en omvänd proxy.

I detta scenario skulle kundens ansvar omfatta följande:

  • Migrera proxywebbplatsen till Kinsta (eller skicka migreringsförfrågningar för att Kinsta ska migrera webbplatsen åt dig).
  • Lägg till en domän på webbplatsen som kommer att användas av den omvänd proxyn. Den omvända proxyn måste riktas till en domän för att komma åt proxywebbplatsen. Vanligtvis används en subdomän för detta ändamål. Till exempel skulle blog.example.com vanligtvis användas för en omvänd proxy som laddar på example.com/blog.
  • Öppna ett supportärende och förse Kinsta’s support team med en klar beskrivning över domän-konfigurationen. Vänligen notera att endast användare med faktura-behörighet (företagsägare, företagsadmin, ekonomiavdelning) kan efterfråga tillägget (add-on).
  • Det kan ta ungefär en arbetsdag för proxywebbplatsen att konfigureras för att ladda över en omvänd proxy.
  • När proxywebbplatsen har konfigurerats skapar du en omvänd proxy på servern som är värd för huvudwebbplatsen.

I detta scenario är Kinstas ansvar, som vi redan tagit upp, begränsat till att konfigurera proxywebbplatsen så att den är redo att laddas över en omvänd proxy.

Endast Huvudwebbplatsen hostas hos Kinsta

Om bara huvudwebbplatsen är hostad hos Kinsta är Kinstas ansvar begränsat till att konfigurera en omvänd proxy för att ladda proxywebbplatsen (hostad någon annanstans). Kinsta kommer att lägga till en standard omvänd proxyregel som anges nedan i denna artikel. Anpassningar till denna regel kan göras på kundens egen begäran.

I det här scenariot behåller klienten ansvaret för att konfigurera proxywebbplatsen så att den laddas ordentligt över den omvända proxyn och för att begära justeringar av omvänd proxy-regeln om den inte korrekt laddar proxywebbplatsen.

Begränsningar av Proxywebbplatser

Det finns vissa inneboende begränsningar för användningen av omvända proxies på Kinsta.

Först, observera att Kinsta inte stöder användningen av multisite över en omvänd proxy.

Kämpar du med driftstopp och WordPress-problem? Kinsta är hosting-lösningen som är utformad för att spara tid! Kolla in våra funktioner

Dessutom kan återställning av säkerhetskopior eller att ta staging-webbplatser live på webbplatser som laddas över en omvänd proxy orsaka att proxywebbplatsen slutar ladda ordentligt. När du arbetar med en proxywebbplats är det alltid lämpligt att schemalägga förändringar som dessa under tider med låg trafik och att samråda med Kinstas supportteam innan du vidtar några åtgärder.

När du arbetar med proxywebbplatser på Kinsta, är det bäst att använda stagingmiljöerna som testmiljöer. Efter testning i en stagingmiljö är det enklaste arbetsflödet att duplicera dessa förändringar på live-webbplatsen istället för att ta stagingwebbplatsen live. Dessutom bör återställning av säkerhetskopior av proxywebbplatser endast göras i en nödsituation när det inte är möjligt att ångra dessa ändringar manuellt.

På grund av dessa begränsningar rekommenderar vi inte användning av proxywebbplatser om du räknar med att rutinmässigt återställa säkerhetskopior eller ta stagingwebbplatser live.

Ett alternativ till proxywebbplatser som är värt att överväga är användningen av en WordPress multisite-installation med underkataloger.

Huvudwebbplats Omvänd Proxy-konfiguration

Det finns två stora konsekvenser för huvudwebbplatsen när du laddar underkataloger över omvända proxies.

  • Omvänd proxy-regler måste läggas till för varje proxy-underkatalog.
  • Huvudwebbplatsen kommer inte att kunna använda proxy-underkataloger för något ändamål som helst eftersom alla förfrågningar till denna underkatalog kommer att vidarebefordras till proxywebbplatsen.

Detta är den standard omvänd proxy-regel för Nginx som används av Kinsta för att ladda en webbplats över en omvänd proxy:

location ^~ /subdirectory/ {
  proxy_pass http://subdirectory.domain.com;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
}

Den faktiska underkatalogen skulle ersättas med platshållaren /subdirectory/. Dessutom skulle http://subdirectory.domain.com ändras för att matcha domänen som används för att rikta den omvända proxyn på proxywebbplatsen.

Konfigurering av Proxywebbplats

För att ladda en webbplats över en omvänd proxy måste följande ändringar göras:

  • En underkatalog måste läggas till i katalogsökvägen på servern, som matchar den underkatalog som används för att ladda webbplatsen, och alla webbplatsfiler flyttas till denna underkatalog.
  • Uppdateringar av webbserverkonfigurationen måste göras för att uppdatera webbplatsens rot för att inkludera den nya underkatalogen. Dessutom måste en omskrivning läggas till i serverkonfigurationen för att ta bort underkatalogen från URI:n för varje inkommande begäran.
  • Alla webbadresser i proxywebbplatsens databas måste uppdateras för att matcha webbadresserna för livewebbplatsen (till exempel example.com/blog).
  • Webbplatsens wp-config.php-fil måste uppdateras med en $_SERVER['HTTP_HOST']-definition som pekar på huvudwebbadressen (example.com i exemplet vi har använt).
  • Om webbplatsen tvingas ladda över https måste ytterligare definitioner läggas till wp-config.php för att undvika omdirigeringsloopar.

Observera att på grund av de nödvändiga omskrivningsreglerna bör en proxywebbplats undvika att skapa webbadresser som duplicerar samma underkatalog under vilken proxywebbplatsen laddas. Till exempel bör en proxywebbplats på example.com/blog undvika att skapa en sida eller katalog på example.com/blog/blog.

Sammanfattning

Användningen av en omvänd proxy på Kinsta är möjlig och vi har ett antal kunder som har valt att använda vår infrastruktur på detta sätt. Det är dock viktigt att förstå den ytterligare tekniska komplexiteten som detta arrangemang introducerar samt konsekvenserna för användningen av Kinstas staging och säkerhetskopieringssystem.

Om du tror att en omvänd proxy är den bästa lösningen på dina nuvarande behov är du välkommen att kontakta Kinstas supportteam via chatt i MyKinsta för att få igång processen!


Om du tyckte om denna tutorial, då kommer du att älska vår support. Alla Kinsta’s hosting planer inkluderar dygnet runt-support från våra rutinerade WordPressutvecklare och ingenjörer. Chatta med samma team som hjälper Fortune 500s kunder. Kolla in våra paket