proxy-sterling
Reverse proxy for www.sterling-insurance.co.uk
Framework:
Links
| URI | Type | |
|---|---|---|
| https://dashboard.heroku.com/apps/proxy-sterling | deployment | |
| https://proxy-sterling.herokuapp.com | heroku url | should not be used or shared publically |
| https://www.sterling-insurance.co.uk | frontend | Main public front end |
| https://adrianflux.co.uk | frontend | To be removed: nominally Cloudflare will redirect this to www |
Overview
This runs dyno(s) on Heroku that act as a reverse proxy for the various applications running under the www.sterling-insurance.co.uk domain.
For example:
https://www.sterling-insurance.co.uk > Main WP on WP Engine
https://www.sterling-insurance.co.uk/blog > Sterling blog on WP Engine
The proxys work with a proxy_pass to a subdomain, e.g blog.sterling.co.uk. Cloudflare DNS for blog.sterling.co.uk will point directly to the site on WP Engine. www.sterling-insurance.co.uk will point to this proxy on Heroku and that will do the routing.
Known Issues
There are limitations regarding this kind of proxying. These can be summarised as:
- Client makes a request to a WP proxied site, i.e. https://www.sterling-insurance.co.uk/blog
- WP Engine is slow to return the response, blocking the NGINX worker
- This worker block affects all requests hitting the
www.sterling-insurance.co.ukdomain, including the main page and other critical pages such as callback. - This problem is exaggerated on cache-misses on WP Engine which happens a lot on requests such as https://www.sterling-insurance.co.uk/blog?some-tracking-code=somerandomsttring as these will always cause a cache miss
- Can cause 2-5 second delays on main site, which blocks the workers again and a negative feedback cycle ensues
Environment Variables
Configuration variables for this application:
PAPERTRAIL_API_TOKEN