moving wordpress to http2 (via https)

    

I just moved my wordpress site to http2 (via https). Some advice on steps to moving your site ;

  • Run it behind nginx + lets encrypt – offload ssl certs and get http2 performance
  • Setup nginx default to redirect all http -> https
  • update your WordPress site to correct URL (via admin / settings / general)  i.e. https://sigtar.com
  • Run WP plug-in to change all media / links to new https links. Else you get mixed secuirty (some http, some https)

SSL caching and redirects in chrome

While setting up SSL reverse proxy using lets encrypt and nginx i  had a few troubles with testing via googles Chrome browser.

  • Chrome caches some SSL responses which can be cleared by deleting your browsing data via settings or Ctrl+Shift+Del.
  • Chrome also caches http -> https redirects, you can see these by going to chrome://net-internals and select “HSTS” from the drop down. Enter the domain name under “Delete domain” and press the Delete button

The easiest thing to do during testing is use incognito mode. You will not need to clear the cache every time you change config or re-issue certificates.

bye bye http – hello letsencrypt

I’ve been a fan of HTTP and caching since my dial-up modem.

Skip to today where google returns HTTPS sites higher in its search results. Its could also be possible that you cannot trust a man in the middle HTTP cache any longer either right? :)

SSL certs have traditionally been expensive, but say welcome to lets encrypt which provides a free way of securing all of your websites. If you haven’t heard of it check it out here – https://letsencrypt.org/

As always i’ve implemented my LetsEncrypt trial via docker. The container image i have been using has been put together by the linuxserver guys  – https://hub.docker.com/r/linuxserver/letsencrypt/
(i use a few of their container images, they seem legit)

This container image comes ready to roll with Nginx built in which can act as a reverse proxy to your unsecured websites at the back-end. I’ll be testing it for the next few days to see how it stacks up, but so far so good. Nginx is fast, so a good transition if only to offload all my SSL traffic. If all goes well it will be the end of my squid reverse proxy which i have used happily for many years.

In the past http had the performance, certs were too difficult (but are they?) and expensive to implement and i was a fan of my sites being cached. New times are here, SSL (TLS) rules supreme.

On another note, HTTP 1 sites are dwindling, SPDY didnt last long but apparently some of that has been built into HTTP/2 – exciting!

Check out these links for some interesting reading on performance –
https://samrueby.com/2015/01/26/why-is-https-faster-than-http/
http://www.httpvshttps.com/

Handy link for testing if your site is using HTTP2 – https://www.ssllabs.com/ssltest/

nginx – setup as reverse proxy

Previously to take down this wordpress site all you needed to do was hold down F5 for about 20 seconds then the site would take about 5 mins to recover.

There were a few factors causing this and quite a few different methods to solving the problem. WordPress itself is run on php / apache, apache has an evasive mod which can block certain IPs depending on the defined abusive behavior (typical DDOS attack). Since i like to run a few websites behind a single IP i looked at fixing the issue closer to the perimeter….

Enter nginx (engine x) as a reverse proxy, the site now typically caches all content and serves it straight out of memory. No longer does mysql / apache kill itself under high load on the backend…

nginx

You will need to create the nginx directories if they dont already exist. Check /var/log/nginx/error.log (default ubuntu) if any issues starting the service.

sudo aptitude install nginx
sudo service nginx start

The following added to http {}
(located in /etc/nginx/nginx.conf)

log_format cache '***$time_local '
'$remote_addr '
'$upstream_cache_status '
'Cache-Control: $upstream_http_cache_control '
'Expires: $upstream_http_expires '
'"$request" ($status) ';
access_log /var/log/nginx/access.log cache;
error_log /var/log/nginx/error.log;
server_names_hash_bucket_size 64;
proxy_cache_path /var/www/nginx_cache levels=1:2
keys_zone=one:10m
max_size=1g inactive=30m;
proxy_temp_path /var/www/nginx_temp;

the following added to location / {}
(located in /etc/nginx/sites-enabled/default)

proxy_pass http://sigtar;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
proxy_redirect off;
proxy_buffering on;
proxy_buffer_size 16k;
proxy_buffers 32 16k;
proxy_cache one;
proxy_cache_valid 200 302 304 10m;
proxy_cache_valid 301 1h;
proxy_cache_valid any 1m;
client_body_buffer_size 128k;
proxy_busy_buffers_size 64k;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass_header Set-Cookie;

Note if you have problems with wordpress redirect issues… check this post;

http://tommcfarlin.com/resolving-the-wordpress-multisite-redirect-loop/

Also confirm you have this line in http {}

server_names_hash_bucket_size 64;

Very basic load test, user load time is reasonably consistent as user count increases.
http://loadimpact.com/load-test/sigtar.com-ad07b7870a75c854a935752b0a032c53

load test