Een reverse proxy kan worden gebruikt om een WordPress Website vanuit een subdirectory te laden, terwijl een volledig afzonderlijke site in het hoofddomein wordt geladen.

Een reverse proxy bestaat uit een set regels die aan een webserver is toegevoegd en die deze server opdracht geeft om verzoeken voor een bepaalde submap naar een afzonderlijke server te verzenden.

Laten we een voorbeeld gebruiken om beter te begrijpen waarvoor een reverse proxy kan worden gebruikt. Stel je voor dat je een niet-WordPress-website hebt die wordt geladen op example.com en WordPress wilt gebruiken om een blog te hebben. Je wil dat die blog wordt weergeven op example.com/blog en je jouw blog wilt hosten bij een managed WordPress-host zoals Kinsta.

Hiervoor moeten reverse proxy regels worden geconfigureerd op de webserver hosting van example.com die de webserver opdraagt om verzoeken voor de /blog subdirectory naar een andere webserver te verzenden die als host fungeert voor de WordPress gedreven /blog website.

Reverse Proxy Add-On

Kinsta staat het gebruik van omgekeerde proxies toe en ondersteunt om WordPress vanuit een subdirectory te laden of om een submap van jouw site naar een externe server te laten verwijzen. Reverse proxy’s zijn echter vaak uitdagend om te configureren en te ondersteunen. Sites die reverse proxies gebruiken, vereisen doorgaans aanzienlijk meer ondersteuning dan standaard WordPress-installaties.

Om deze reden is er een maandelijks add-on abonnement van $50 voor elke reverse proxy die Kinsta ondersteunt bij het opzetten of wordt gevraagd om te ondersteunen.

Ga bovendien ook uit van maximaal één volledige werkdag voor de initiële installatie van een reverse proxy. In sommige gevallen kan extra tijd en samenwerking met het Kinsta-ondersteuningsteam nodig zijn om de reverse proxy correct te laten werken.

Reverse Proxy Casussen

Er zijn drie gebruiksmogelijkheden voor reverse proxies bij Kinsta. Om deze gevallen te begrijpen, moeten we eerst twee termen definiëren: hoofdsite en proxy-site.

  • De hoofdsite is de site die wordt geladen vanuit het hoofddomein.
  • De proxy-site is de site die vanuit een submap wordt geladen via een reverse proxy.

Terugkomend op ons voorbeeld hierboven, zou example.com de hoofdsite zijn, terwijl example.com/blog de proxy-site is.

Met die definities in gedachten, zijn hier de drie mogelijke casussen voor reverse proxies bij Kinsta:

  • Hoofd- en proxy-site die beide worden gehost door Kinsta: de hoofdsite, example.com en de proxy-site example.com/blog worden beide gehost bij Kinsta. Dit zou het mogelijk maken om één WordPress-installatie om example.com aan te sturen, terwijl een volledig afzonderlijke WordPress-installatie word gebruikt voor example.com/blog.
  • Proxy-site gehost door Kinsta: de hoofdsite, example.com, wordt niet door Kinsta gehost terwijl de proxy-site example.com/blog wel wordt gehost door Kinsta. Hierdoor kan een WordPress-installatie die wordt gehost bij Kinsta worden gebruikt op example.com/blog, terwijl de hoofdsite ergens anders wordt gehost.
  • Hoofdsite wordt gehost door Kinsta: de hoofdsite, example.com, wordt gehost door Kinsta, terwijl de proxy-site example.com/blog niet wordt gehost door Kinsta. Hierdoor kan een WordPress-installatie die word gehost bij Kinsta worden gebruikt voor example.com, terwijl de subdirectory van de blog ergens anders word gehost.

Laten we de implicaties van elke mogelijkheid bekijken, in het bijzonder zullen we de beperkingen van Kinsta’s ondersteuning voor elk scenario behandelen.

Voorbeel van een Reverse proxy server

Voorbeel van een Reverse proxy server

Hoofd- en Proxy-site gehost door Kinsta

Wanneer beide sites worden gehost bij Kinsta, kan het ondersteuningsteam van Kinsta de nodige reverse proxy regels instellen op de hoofdsite en ook de proxy-site configureren om via de reverse proxy te laden. Houd er rekening mee dat zowel de hoofdsite als de proxy-site zich in hetzelfde datacenter moeten bevinden. Verder is er een korte downtime mogelijk tijdens het instellen van de reverse proxy terwijl Kinsta de sites op hun plaats zet.

In dit scenario is de klant verantwoordelijk voor het volgende:

  • Migreer beide sites naar de Kinsta-omgeving (of dien migratieverzoeken in om Kinsta de sites te laten migreren).
  • Geef het ondersteuningsteam van Kinsta een duidelijke beschrijving van de domein configuratie.
  • Sta ongeveer één werkdag toe voor elke reverse proxy setup.

In dit scenario zijn de verantwoordelijkheden van Kinsta het volgende:

  • De nodige reverse proxy-regels instellen op de hoofdsite.
  • De proxy-site configureren om via de reverse proxy te laden.

Alleen de Proxy-site wordt gehost door Kinsta

Belangrijke opmerking: als alleen de proxy-site wordt gehost bij Kinsta, moeten jij de IP-adressen van de proxyserver verstrekken en de proxyserver configureren om de headers in onze standaard Nginx reverse proxy-regel in te stellen. Deze stappen zijn vereist om ervoor te zorgen dat ons analysesysteem correct werkt en dat we jouw IP-adressen van de proxyserver niet op de blacklist plaatsen.

Als alleen de proxy-site door Kinsta wordt gehost, is Kinsta niet in staat om de reverse proxy in te stellen, omdat dit moet worden geconfigureerd op de server die de hoofdsite host. In dit scenario is Kinsta’s verantwoordelijkheid beperkt tot het configureren van de proxy-site, zodat deze klaar is om via een reverse proxy te worden geladen.

In dit scenario is de klant verantwoordelijk voor het volgende:

  • Migreer de proxy-site naar Kinsta (of dien een migratieaanvraag in om Kinsta de site te laten migreren).
  • Voeg een domein toe aan de site die door de reverse proxy wordt gebruikt. De reverse proxy moet naar een domein wijzen om toegang te krijgen tot de proxy-site. Meestal wordt hier een subdomein voor gebruikt. Bijvoorbeeld: blog.example.com wordt meestal gebruikt voor het reverse proxy laden van example.com/blog.
  • Geef het ondersteuningsteam van Kinsta een duidelijke beschrijving van de domein configuratie.
  • Wacht ongeveer één werkdag om de proxy-site geconfigureerd te laten worden om via een reverse proxy te laden.
  • Nadat de proxy-site is geconfigureerd, maak je de reverse proxy aan op de server die de hoofdsite host.

In dit scenario, zoals eerder vermeld, is de verantwoordelijkheid van Kinsta beperkt tot het configureren van de proxy-site, zodat deze correct is ingesteld om via een omgekeerde proxy te laden.

Alleen de Hoofdsite word Gehost door Kinsta

Als alleen de hoofdsite wordt gehost door Kinsta, is de verantwoordelijkheid van Kinsta beperkt tot het instellen van de reverse proxy om de proxy-site te laden (die elders wordt gehost). Kinsta zal de standaard reverse proxy-regel toevoegen die in dit artikel wordt vermeld. Aanpassingen van deze regel kunnen op verzoek van de klant worden aangebracht.

In dit scenario blijft de klant verantwoordelijk voor het configureren van de proxy-site zodat deze correct wordt geladen via de reverse proxy en voor het aanvragen van aanpassingen aan de reverse proxy-regel wanneer de proxy-site niet correct wordt geladen.

Beperkingen van Proxy-Sites

Er zijn enkele beperkingen inherent aan het gebruik van reverse proxies bij Kinsta.

Merk als eerste op dat Kinsta het gebruik van een multisite via een reverse proxy niet ondersteunt.

Bovendien kan het herstellen van back-ups of het pushen van tijdelijke staging-sites op sites die via een reverse proxy worden geladen ervoor zorgen dat de proxy-site niet meer correct wordt geladen. Wanneer je met een proxy-site werkt, is het altijd raadzaam om dergelijke wijzigingen in te plannen ten tijden van weinig verkeer en om het supportteam van Kinsta te raadplegen voordat je actie onderneemt.

Bij Kinsta, als het gaat om proxy-sites, is het beste gebruik van de staging-omgeving als een testomgeving. Na het testen op staging is de eenvoudigste workflow om die wijzigingen op de live site te dupliceren in plaats van de staging-omgeving naar live te pushen. Bovendien moet het terugzetten van back-ups van een proxy-site alleen worden gedaan in een noodgeval wanneer het handmatig terugdraaien van wijzigingen niet mogelijk is.

Vanwege deze beperkingen raden we het gebruik van proxy-sites niet aan als je verwacht dat je regelmatig back-ups terugzet of regelmatig staging-omgevingen naar live-omgevingen pusht.

Een alternatief voor proxy-sites die het overwegen waard is, is het gebruik van een WordPress multisite-installatie met submappen.

Hoofdsite Reverse Proxy Configuratie

Er zijn twee belangrijke implicaties voor de hoofdsite bij het laden van subdirectories via reverse proxies.

  • Reverse proxy-regels moeten voor elke proxy submap worden toegevoegd.
  • De hoofdsite kan de proxy submappen niet gebruiken voor welk doel dan ook, omdat alle verzoeken voor die subdirectory zullen worden doorgestuurd naar de proxy-site.

Dit is de standaard Nginx reverse proxy-regel die door Kinsta wordt gebruikt om een site via een reverse proxy te laden:

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;
}

De eigenlijke subdirectory zou worden vervangen door de /subdirectory/ placeholder. Bovendien zou http://subdirectory.domain.com worden gewijzigd om overeen te komen met het domein dat wordt gebruikt om de reverse proxy op de proxy-site aan te wijzen.

Proxy-site Configuratie

Om een site via een reverse proxy te laden moeten de volgende wijzigen doorgevoerd worden:

  • Er moet een submap aan het directory-pad op de server worden toegevoegd, overeenkomend met de subdirectory die wordt gebruikt om de site te laden en alle website-bestanden moeten naar deze submap worden verplaatst.
  • Updates aan de configuratie van de webserver moeten worden gemaakt om de root van de website bij te werken om de nieuwe subdirectory op te nemen. Bovendien moet er een rewrite aan de server-configuratie worden toegevoegd om de submap uit de aanvraag-URI te verwijderen voor elke inkomend verzoek.
  • Alle URL’s in de proxy site-database moeten worden bijgewerkt om overeen te komen met de live site-URL’s (bijvoorbeeld example.com/blog).
  • Het wp-config.php bestand van de site moet worden bijgewerkt met een $_SERVER['HTTP_HOST'] definitie die verwijst naar de hoofdsite-URL (example.com in het voorbeeld dat we gebruiken).
  • Als de site wordt gedwongen om via https te laden, moeten extra definities aan de wp-config.php worden toegevoegd om redirect-lussen te voorkomen.

Merk op dat vanwege de noodzakelijke rewrite-regels, een proxy-site moet voorkomen dat er URL’s worden gemaakt die dezelfde submap dupliceren waaronder de proxy-site wordt geladen. Een proxy-site op example.com/blog moet bijvoorbeeld voorkomen dat er een pagina of directory wordt gemaakt op example.com/blog/blog.

Samenvatting

Het gebruik van reverse proxies bij Kinsta is mogelijk en we hebben een aantal klanten die ervoor hebben gekozen onze infrastructuur op deze manier te gebruiken. Het is echter belangrijk om inzicht te hebben in de extra technische complexiteit die deze regeling introduceert, evenals de implicaties voor het gebruik van Kinsta’s staging- en back-up-systemen.

Als je denkt dat een reverse proxy de beste oplossing is voor jouw huidige behoefte, neem dan gerust contact op met het ondersteuningsteam van Kinsta via een chat in MyKinsta om het proces op gang te krijgen!

9
Delen