• CentOS: Using NGinx as an SSL Reverse Proxy for Apache

    A little while ago, I published a guide to configuring NGinx to act as a Reverse Proxy for Apache. Although it was briefly mentioned, we never went through the steps necessary to configure NGinx to work in this manner for SSL connections - we simply left Apache listening on port 443.

    This documentation details how to go about configuring NGinx to handle your SSL stuff as well. It assumes you've already generated CSR's and got the SSL certificate to use (presumably because they're already being used by Apache).

  • Joomla and NGinx Reverse Proxy Caching: Keeping your dynamic content fresh

    We've placed a caching NGinx reverse proxy in front of our Joomla site, but haven't yet addressed the issue of the content that we do want to remain dynamic. We might, for example, have a module such as mod_GoogPlusFeed embedded on a number of pages, but with the configuration we've used so far, this won't update until the cached copy has expired.

    In this guide, we're going to walk through the few easy steps to ensure the content is regularly updated - without undermining what we were originally trying to achieve - fast response times.

    The primary basis of what we're going to do is very similar to Dealing with Slow modules and Caching, so much so that some of the set up is the same

  • Keeping Hitcounts accurate when using an NGinx Caching Proxy

    In previous documentation, we've configured sites to use NGinx as a Reverse Caching Proxy, leading to hugely improved response times on popular content. We've also implemented a custom configuration so that we can refresh the cache periodically, ensuring that dynamic content (such as Twitter modules) updates.

    One thing we haven't done as yet, though, is to address the issue of internal hitcounts. We've looked specifically at using NGinx with Joomla, and noted that a side effect would be inaccurate hitcounts displayed within Joomla (which remains true even when using the internal page caching).

    In this documentation, we'll be implementing a small script to ensure that hits served from the cache are still recorded within Joomla (or Wordpress, Drupal - whatever you happen to be using), albeit a little while after they happen.

  • Making your Joomla Site Fly with NGinx Reverse Proxy Caching

    I've written previously about configuring NGinx to act as a reverse proxy for Apache, as well as some of the specific tweaks you need to make if you're serving a Joomla! based site. In this documentation, we're going to look at how to use NGinx's Reverse Proxy caching feature to make your site really fly.

    There are a small number of technical hurdles which we'll overcome to ensure that the user is experience is fast and smooth without losing interactivity on those sites which demand it. 

  • Nginx logs two upstream statuses for one upstream

    I'm a big fan (and user) of NGinx

    Just occasionally, though, you'll find something that looks a little odd - despite having quite a simple underlying explanation.

    This one falls firmly into that category.

    When running NGinx using ngx_http_proxy_module (i.e. using proxy_pass), you may sometimes see two upstream status codes recorded (specifically in the variable upstream_status) despite only having a single upstream configured.

    So assuming a logformat of

    '$remote_addr\t-\t$remote_user\t[$time_local]\t"$request"\t'
    '$status\t$body_bytes_sent\t"$http_referer"\t'
    '"$http_user_agent"\t"$http_x_forwarded_for"\t"$http_host"\t$up_host\t$upstream_status';
    

    You may, for example, see a logline line this

    1.2.3.4	-	-	[11/Jun/2020:17:26:01 +0000]	"GET /foo/bar/test/ HTTP/2.0"	200	60345109	"-"	"curl/7.68.0"	"-"	"testserver.invalid"	storage.googleapis.com	502, 200
    

    Note the two comma-seperated status codes at the end of the line, we observed two different upstream statuses (though we only passed the 200 downstream).

    This documentation helps explain why this happens.