Returning custom HTTP headers from nginx

Using curl -v against your site you can easily check the headers being returned from your nginx server. To see only the HTTP exchange without the actual HTML content you can send the output to /dev/null:

curl -v -o /dev/null

By default my site is returning:

< Server: nginx
< Date: Sat, 29 Jul 2017 20:12:10 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Link: <>; rel=""
< Link: <>; rel=shortlink

To add additional headers, such as XSS prevention headers:

X-XSS-Protection: 1; mode=block

Edit your nginx.conf and add to your server { } block:

add_header X-XSS-Protection "1; mode=block";

To hide X-Powered-By headers if you are using fastcgi (see here), add:

fastcgi_hide_header X-Powered-By;


Windows audio drivers for Windows 10 on a Mac Pro 2008

Windows 10 runs surprisingly well on my (new) Mac Pro 2008. The Bootcamp driver download from Apple though is no longer supported on a 2008:

The main feature I’m particularly missing is the Bootcamp systray app in Windows to allow you to pick your boot drive, i.e. to select to boot back to MacOS from Windows. As long as you can get to the boot screen and pick which partition to boot from then this is ok (although since I’ve also added a PC version (unflashed) of an Nvidia 750 Ti, whenever I want to switch OSes, I have to switch my monitor cable between the stock Mac ATI card, and then switch it back to my 750 Ti after I’ve picked which OS I want to boot).

Without getting all the Windows drivers installed in one go from Bootcamp, the only other thing I missed initially (before finding this post), was Audio drivers. Windows 10 had installed some default drivers but the volume control didn’t have any control over the speakers plugged into either the front or rear audio out. Downloading the Realtek drivers direct from this site fixed this though. After installing the drivers, the names of the audio out devices changes on the volume control too:

Now I’m all set 🙂

nginx redirecting http requests to https

If you have your nginx server setup with valid SSL certificates to support https, you can redirect all http incoming requests to https with a simple 301 ‘Permanently Moved’ response to the client.

Returning a 301 is considered best practice for enforcing an http to https upgrade.

This post covers this approach, which involves configuring a server block for port 80 to always respond with a 301 response including the https url:

server {
    listen 80;
    listen [::]:80;
    return 301$request_uri;

The example config in the above article also shows how to redirect first to your server defined with no subdomain, and then additionally redirect from the request with no subdomain to your www subdomain, e.g from to then to Apparently the way nginx caches server names there’s performance advantages to redirect to a no-name subdomain first. Redirecting directly to your www subdomain obviously still works too.

WordPress migration complete! (From OpenShift Online to a VPS)

If you’re reading this then I’ve successfully migrated this WordPress site from Red Hat OpenShift Online to hosting in a Virtual Private Server (VPS). I had a rather long list of tasks for the migration, including:

  • Exporting content from the old site and importing to the new
  • Re-issuing my SSL certificate and installing on the new server
  • Updating my DNS config
  • Unassociating my deployed app on Openshift with my domain name / alias
  • Installing my WordPress plugins, such as reCAPTCHA, view counter, the importer etc

I’m probably still missing some minor config items, but at this point I think I’m far enough to make the switch, so the site is now live on my new VPS hosting.

Given that I’m only running on a 2 core, 512MB RAM VPS, the new site is surprisingly snappy, and dare I say it, noticeably quicker than when it was running before on OpenShift Online? I’m sure I’ve still got plenty to tweak and configure, but so far so good, and I’m pleased with the transition!