9 Jul
2022
9 Jul
'22
10:31 a.m.
Hi all,
I’ve been banging my head against this issue for a couple of weeks and I’m hoping someone
here can provide some guidance or sugestions.
Some Background
I run several WordPress sites on my Bitfolk VPS, and I have AWS CloudFront in front of
them. Because CloudFront serves the www.domain.name<http://www.domain.name> URLs, I
have origin-www.domain.name DNS entries pointing to my VPS, and Apache VirtualHosts
configured that respond to multiple ServerNames and ServerAliases:
* domain.name
* origin-www.domain.name
* www.domain.name
* www-test.domain.name
On the VPS I am serving the websites over HTTP and HTTPS (using Let’s Encrypt for
certificates), but CloudFront is configured to redirect HTTP requests to HTTPS (using AWS
Certificate Manager certificates), and to only communicate with the origin over HTTPS. The
Apache VirtualHosts are configured to redirect any domain name to https://www.domain.name,
which is the URL that each WordPress site is configured to use (for the WordPress Address
and the Site Address).
Now to the problem
I see different behaviours with the redirects on different websites. For example, if I
test all the URI combinations for one of my sites using a site like
https://httpstatus.io/, I get:
1. http://wofeckcsclub.co.uk --> https://wofeckcsclub.co.uk -->
https://www.wofeckcsclub.co.uk --> website loads
2. http://origin-www.wofeckcsclub.co.uk --> https://www.wofeckcsclub.co.uk -->
website loads
3. http://www.wofeckcsclub.co.uk --> https://www.wofeckcsclub.co.uk --> website
loads
4. http://www-test.wofeckcsclub.co.uk --> https://www-test.wofeckcsclub.co.uk -->
https://www.wofeckcsclub.co.uk --> website loads
5. https://wofeckcsclub.co.uk --> https://www.wofeckcsclub.co.uk --> website
loads
6. https://origin-www.wofeckcsclub.co.uk --> https://www.wofeckcsclub.co.uk -->
website loads
7. https://www.wofeckcsclub.co.uk --> website loads
8. https://www-test.wofeckcsclub.co.uk --> https://www.wofeckcsclub.co.uk -->
website loads
On the whole, this is fine. I’d rather 1) and 4) had a single redirect to
https://www.wofeckcsclub.co.uk but I think this is a result of CloudFront first
redirecting to HTTPS and then the HTTPS site redirecting to the correct URI, so not sure I
can do much about this (except maybe enable CloudFront to communicate with the origin via
HTTP, and allow the HTTP origin site to redirect to the correct URI).
However, a few of my websites do this instead:
1. http://savouredescapes.com --> https://savouredescapes.com -->
https://www.savouredescapes.com --> website loads
2. http://origin-www.savouredescapes.com --> https://www.savouredescapes.com -->
website loads
3. http://www.savouredescapes.com --> https://www.savouredescapes.com --> website
loads
4. http://www-test.savouredescapes.com --> https://www.savouredescapes.com -->
website loads
5. https://savouredescapes.com --> https://www.savouredescapes.com --> website
loads
6. https://origin-www.savouredescapes.com --> website loads [not correct]
7. https://www.savouredescapes.com --> website loads
8. https://www-test.savouredescapes.com --> website loads [not correct]
For these websites, URIs 6) and 8) are not being redirected, and display the website with
the original URI in the browser. All the VirtualHosts are configured the same, and look
like this:
<VirtualHost *:80>
DocumentRoot /var/www/savouredescapes
ServerName www.savouredescapes.com
ServerAlias savouredescapes.com origin-www.savouredescapes.com
www-test.savouredescapes.com
<Directory /var/www/savouredescapes/>
AllowOverride All
</Directory>
ErrorDocument 403 /error/noindex.html
ErrorLog ${APACHE_LOG_DIR}/savouredescapes-error.log
CustomLog ${APACHE_LOG_DIR}/savouredescapes-access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =savouredescapes.com [OR]
RewriteCond %{SERVER_NAME} =origin-www.savouredescapes.com [OR]
RewriteCond %{SERVER_NAME} =www.savouredescapes.com [OR]
RewriteCond %{SERVER_NAME} =www-test.savouredescapes.com
RewriteRule ^ https://www.savouredescapes.com%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
As far as I can tell, a URI like https://origin-www.savouredescapes.com should be hitting
my VPS direct (no CloudFront, DNS points to my VPS) and getting redirected to
https://www.savouredescapes.com, which should then be served via CloudFront. However,
Apache doesn’t seem to be performing this redirect. In the Apache logs, I see entries like
this in the ‘access’ log:
188.166.109.207 - - [09/Jul/2022:11:19:04 +0100] "GET / HTTP/1.1" 200 58957
"-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101
Firefox/102.0"
As opposed to something like this when the redirect does work:
188.166.109.207 - - [09/Jul/2022:11:11:18 +0100] "GET / HTTP/1.1" 301 568
"-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101
Firefox/102.0"
And nothing in the error logs. So I’m not sure how to troubleshoot further why the
redirects aren’t working as expected for this particular website.
In addition, because this does work on some of my other sites (like the
https://www.wofeckcsclub.co.uk site I first showed the results for), I presume WordPress
(or something else?!?) must be doing an internal redirect, rather than Apache? Again, as
far as I can tell the WordPress configurations are the same; there are no obvious plugins
that would configure 301/302 redirects on the WordPress instances that do work, although
that’s not to say such a plugin hasn’t been installed and configured in the past and since
removed, leaving the configuration running on the WordPress site…?
I’m wondering if anyone on this list has any relevant WordPress experience, and any
suggestions for files/configurations to check in WordPress to see where these redirects
might be happening? Also more than happy to explore the fact that my Apache configuration
could be wrong and need tuning, and open to any other suggestions to try and ‘fix’ these
redirects one way or another (the main thing I want is consistency across all of them!).
Many thanks in advance,
Paul
9 Jul
9 Jul
11:55 a.m.
Hi Paul,
I'm not an expert at this but I did notice some things.
On Sat, Jul 09, 2022 at 10:31:41AM +0000, Paul Lewis via BitFolk Users wrote:
Now to the problem
6. https://origin-www.wofeckcsclub.co.uk --> https://www.wofeckcsclub.co.uk -->
website loads
6. https://origin-www.savouredescapes.com -->
website loads [not correct]
Just reducing this to an example of behaviour you want vs behaviour
you don't want…
All the VirtualHosts are configured the same, and look
like this:
<VirtualHost *:80>
DocumentRoot /var/www/savouredescapes
ServerName www.savouredescapes.com
ServerAlias savouredescapes.com origin-www.savouredescapes.com
www-test.savouredescapes.com
<Directory /var/www/savouredescapes/>
AllowOverride All
</Directory>
ErrorDocument 403 /error/noindex.html
ErrorLog ${APACHE_LOG_DIR}/savouredescapes-error.log
CustomLog ${APACHE_LOG_DIR}/savouredescapes-access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =savouredescapes.com [OR]
RewriteCond %{SERVER_NAME} =origin-www.savouredescapes.com [OR]
RewriteCond %{SERVER_NAME} =www.savouredescapes.com [OR]
RewriteCond %{SERVER_NAME} =www-test.savouredescapes.com
RewriteRule ^ https://www.savouredescapes.com%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
The first thing that strikes me is that this virtualhost is only for
port 80. Port 443 (https) connections aren't going to hit this vhost
at all, I don't think. Where do port 443 connections go?
The other thing I notice is that when I do:
$ curl -s -v https://origin-www.wofeckcsclub.co.uk > /dev/null
I see:
GET / HTTP/1.1
Host: origin-www.wofeckcsclub.co.uk
User-Agent: curl/7.64.0
Accept: */*
[…]
< HTTP/1.1 301 Moved Permanently
< Date: Sat, 09 Jul 2022 11:46:41 GMT
< Server: Apache/2.4.29 (Ubuntu)
< X-Redirect-By: WordPress
< Location: https://www.wofeckcsclub.co.uk/
Whereas with
$ curl -s -v https://origin-www.savouredescapes.com/ > /dev/null
GET / HTTP/1.1
Host: origin-www.savouredescapes.com
User-Agent: curl/7.64.0
Accept: */*
[…]
< HTTP/1.1 200 OK
< Date: Sat, 09 Jul 2022 11:49:12 GMT
< Server: Apache/2.4.29 (Ubuntu)
< Link: <https://www.savouredescapes.com/wp-json/>;
rel="https://api.w.org/"
< Link: <https://wp.me/7loaj>; rel=shortlink
< Vary: Accept-Encoding
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=UTF-8
etc. it serves a web page, no redirect by Wordpress.
So I think maybe there is some setting different in Wordpress
between your two example sites.
Note that even your working example doesn't redirect by your Apache
config, it redirects by Wordpress.
Also I am guessing there is actually more to your config otherwise
what is the point of all the additional names? I assume you're
recognising Cloudfront by some means and not redirecting them back
on themselves infinitely and by the same token your "test" URIs
presumably don't redirect (intentionally) for you when you are
testing them.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
12:45 p.m.
Hi Andy,
Thanks for taking a look. Comments and answers to your questions inline below.
Many thanks,
Paul
+44 (0) 773 996 2121
From: Andy Smith via BitFolk Users <users(a)mailman.bitfolk.com>
Date: Saturday, 9 July 2022 at 12:56
To: users(a)mailman.bitfolk.com <users(a)mailman.bitfolk.com>
Cc: Andy Smith <andy(a)bitfolk.com>
Subject: [bitfolk] Re: Help with Apache serving incorrect VirtualHost DocumentRoot
Hi Paul,
I'm not an expert at this but I did notice some things.
On Sat, Jul 09, 2022 at 10:31:41AM +0000, Paul Lewis via BitFolk Users wrote:
Now to the problem
6. https://origin-www.wofeckcsclub.co.uk --> https://www.wofeckcsclub.co.uk -->
website loads
6. https://origin-www.savouredescapes.com -->
website loads [not correct]
Just reducing this to an example of behaviour you want vs behaviour
you don't want…
[PJL] This is correct.
All the VirtualHosts are configured the same, and look
like this:
<VirtualHost *:80>
DocumentRoot /var/www/savouredescapes
ServerName www.savouredescapes.com<http://www.savouredescapes.com>
ServerAlias savouredescapes.com origin-www.savouredescapes.com
www-test.savouredescapes.com
<Directory /var/www/savouredescapes/>
AllowOverride All
</Directory>
ErrorDocument 403 /error/noindex.html
ErrorLog ${APACHE_LOG_DIR}/savouredescapes-error.log
CustomLog ${APACHE_LOG_DIR}/savouredescapes-access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =savouredescapes.com [OR]
RewriteCond %{SERVER_NAME} =origin-www.savouredescapes.com [OR]
RewriteCond %{SERVER_NAME} =www.savouredescapes.com [OR]
RewriteCond %{SERVER_NAME} =www-test.savouredescapes.com
RewriteRule ^
https://www.savouredescapes.com%{REQUEST_URI}<https://www.savouredescape…
[END,NE,R=permanent]
</VirtualHost>
The first thing that strikes me is that this virtualhost is only for
port 80. Port 443 (https) connections aren't going to hit this vhost
at all, I don't think. Where do port 443 connections go?
[PJL] Yes, you’re right, I didn’t include the SSL VirtualHost, which is pretty much
identical, but with SSL certificates and configured and the RewriteConds commented out:
<IfModule mod_ssl.c>
<VirtualHost *:443>
DocumentRoot /var/www/savouredescapes
ServerName www.savouredescapes.com
ServerAlias savouredescapes.com origin-www.savouredescapes.com
www-test.savouredescapes.com
<Directory /var/www/savouredescapes/>
AllowOverride All
</Directory>
ErrorDocument 403 /error/noindex.html
ErrorLog ${APACHE_LOG_DIR}/savouredescapes-error.log
CustomLog ${APACHE_LOG_DIR}/savouredescapes-access.log combined
RewriteEngine on
# Some rewrite rules in this file were disabled on your HTTPS site,
# because they have the potential to create redirection loops.
# RewriteCond %{SERVER_NAME} =savouredescapes.com [OR]
# RewriteCond %{SERVER_NAME} =origin-www.savouredescapes.com [OR]
# RewriteCond %{SERVER_NAME} =www.savouredescapes.com [OR]
# RewriteCond %{SERVER_NAME} =www-test.savouredescapes.com
# RewriteRule ^ https://www.savouredescapes.com%{REQUEST_URI} [END,NE,R=permanent]
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/savouredescapes.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/savouredescapes.com/privkey.pem
</VirtualHost>
</IfModule>
Note: Let’s Encrypt sets up the redirect rules for the HTTP virtual host (I edit the
RewriteRule to go to the specific www URI I want, rather than using the generic
${SERVER_NAME} URI Let’s Encrypt adds by default), and comments them out in the HTTPS
virtual host, to avoid potential redirect loops, as per the comment. I think I could
re-enable these rules without creating those loops, but as you point out below, it doesn’t
seem that Apache’s doing the redirects anyway, so maybe this config is all just pointless
and should be removed.
The other thing I notice is that when I do:
$ curl -s -v https://origin-www.wofeckcsclub.co.uk > /dev/null
I see:
GET / HTTP/1.1
Host: origin-www.wofeckcsclub.co.uk
User-Agent: curl/7.64.0
Accept: */*
[…]
< HTTP/1.1 301 Moved Permanently
< Date: Sat, 09 Jul 2022 11:46:41 GMT
< Server: Apache/2.4.29 (Ubuntu)
< X-Redirect-By: WordPress
< Location: https://www.wofeckcsclub.co.uk/
Whereas with
$ curl -s -v https://origin-www.savouredescapes.com/ > /dev/null
GET / HTTP/1.1
Host: origin-www.savouredescapes.com
User-Agent: curl/7.64.0
Accept: */*
[…]
< HTTP/1.1 200 OK
< Date: Sat, 09 Jul 2022 11:49:12 GMT
< Server: Apache/2.4.29 (Ubuntu)
< Link: <https://www.savouredescapes.com/wp-json/>;
rel="https://api.w.org/"
< Link: <https://wp.me/7loaj>; rel=shortlink
< Vary: Accept-Encoding
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=UTF-8
etc. it serves a web page, no redirect by Wordpress.
[PJL] Yes, I think I had noticed this too during the past couple of weeks, just forgot to
mention that in my email. This is probably why I was thinking that WordPress is doing
some/all of the directs too.
So I think maybe there is some setting different in Wordpress
between your two example sites.
[PJL] Yeah, this is pretty much what I expected, and would definitely appreciate any help
that people can offer on this. I know that WordPress can redirect in a multitude of ways,
including:
* .htaccess file config
* Plugins
* wp-config.php config
and I’m sure there are plenty of others. The .htaccess files are the same across all my
WordPress sites, and one site had the wp-config.php configuration, but continues to
redirect correctly even after removing it!
Maybe I should just install a plugin and be done with it.
Note that even your working example doesn't redirect by your Apache
config, it redirects by Wordpress.
Also I am guessing there is actually more to your config otherwise
what is the point of all the additional names? I assume you're
recognising Cloudfront by some means and not redirecting them back
on themselves infinitely and by the same token your "test" URIs
presumably don't redirect (intentionally) for you when you are
testing them.
[PJL] Yes, it’s a lot of hostnames. When I was hosting the websites directly off the VPS
it was much simpler: domain.name was an A record and AAAA record pointing to the VPS, and
www.domain.name was a CNAME pointing to domain.name. But when you introduce a CDN, you
need to address the origin somehow – and not by a common name like www.domain.name, hence
the introduction of origin-www.domain.name. The www-test.domain.name was a new one that I
introduced recently during testing, as a name I could quickly switch between pointing at
the VPS or the CDN to test if everything was working, without impacting actual visitors to
the website.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
11 Jul
11 Jul
2:33 p.m.
If I could chip in below...
On 09/07/2022 13:45, Paul Lewis via BitFolk Users wrote:
<snip>
The first thing that strikes me is that this virtualhost is only for
port 80. Port 443 (https) connections aren't going to hit this vhost
at all, I don't think. Where do port 443 connections go?
[PJL] Yes, you’re right, I didn’t include the SSL VirtualHost, which
is pretty much identical, but with SSL certificates and configured and
the RewriteConds commented out:
<IfModule mod_ssl.c>
<VirtualHost *:443>
DocumentRoot /var/www/savouredescapes
ServerName www.savouredescapes.com
ServerAlias savouredescapes.com origin-www.savouredescapes.com
www-test.savouredescapes.com
<Directory /var/www/savouredescapes/>
AllowOverride All
</Directory>
ErrorDocument 403 /error/noindex.html
ErrorLog ${APACHE_LOG_DIR}/savouredescapes-error.log
CustomLog ${APACHE_LOG_DIR}/savouredescapes-access.log combined
RewriteEngine on
# Some rewrite rules in this file were disabled on your HTTPS site,
# because they have the potential to create redirection loops.
# RewriteCond %{SERVER_NAME} =savouredescapes.com [OR]
# RewriteCond %{SERVER_NAME} =origin-www.savouredescapes.com [OR]
# RewriteCond %{SERVER_NAME} =www.savouredescapes.com [OR]
# RewriteCond %{SERVER_NAME} =www-test.savouredescapes.com
# RewriteRule ^ https://www.savouredescapes.com%{REQUEST_URI}
[END,NE,R=permanent]
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/savouredescapes.com/fullchain.pem
SSLCertificateKeyFile
/etc/letsencrypt/live/savouredescapes.com/privkey.pem
</VirtualHost>
</IfModule>
Note: Let’s Encrypt sets up the redirect rules for the HTTP virtual
host (I edit the RewriteRule to go to the specific www URI I want,
rather than using the generic ${SERVER_NAME} URI Let’s Encrypt adds by
default), and comments them out in the HTTPS virtual host, to avoid
potential redirect loops, as per the comment. I think I could
re-enable these rules without creating those loops, but as you point
out below, it doesn’t seem that Apache’s doing the redirects anyway,
so maybe this config is all just pointless and should be removed.
<snip>
I would definitely suggest uncommenting as below so that https requests
are correctly redirected to
https://www.savouredescapes.com%{REQUEST_URI} then checking if Apache is
logging connections to those URLS or Wordpress is intercepting first
(are any of the non-final URLs in your list of sites in Wordpress?).
RewriteCond %{SERVER_NAME} =savouredescapes.com [OR]
RewriteCond %{SERVER_NAME} =origin-www.savouredescapes.com [OR]
# RewriteCond %{SERVER_NAME} =www.savouredescapes.com [OR]
RewriteCond %{SERVER_NAME} =www-test.savouredescapes.com
RewriteRule ^ https://www.savouredescapes.com%{REQUEST_URI}
[END,NE,R=permanent]
Gavin
9 Jul
9 Jul
1:29 p.m.
Hi,
This sounds to me like a wordpress problem.
Within the wordpress database, you will find a ???-options table, where
??? is the prefix for the site. See wp-config.php in the site's root
directory.
The first two entries in that table are the "siteurl" and "home" urls.
If these are wrong, you will find your website redirects with a 301.
Regards
Ian
On 09/07/2022 17:31, Paul Lewis via BitFolk Users wrote:
Hi all,
I’ve been banging my head against this issue for a couple of weeks and
I’m hoping someone here can provide some guidance or sugestions.
_Some Background_
I run several WordPress sites on my Bitfolk VPS, and I have AWS
CloudFront in front of them. Because CloudFront serves the
www.domain.name <http://www.domain.name> URLs, I have
origin-www.domain.name <origin-www.domain.name> DNS entries pointing to
my VPS, and Apache VirtualHosts configured that respond to multiple
ServerNames and ServerAliases:
* domain.name
* origin-www.domain.name
* www.domain.name
* www-test.domain.name
On the VPS I am serving the websites over HTTP and HTTPS (using Let’s
Encrypt for certificates), but CloudFront is configured to redirect HTTP
requests to HTTPS (using AWS Certificate Manager certificates), and to
only communicate with the origin over HTTPS. The Apache VirtualHosts are
configured to redirect any domain name to https://www.domain.name, which
is the URL that each WordPress site is configured to use (for the
WordPress Address and the Site Address).
_Now to the problem_
__
I see different behaviours with the redirects on different websites. For
example, if I test all the URI combinations for one of my sites using a
site like https://httpstatus.io/ <https://httpstatus.io/>, I get:
1. http://wofeckcsclub.co.uk <http://wofeckcsclub.co.uk> -->
https://wofeckcsclub.co.uk <https://wofeckcsclub.co.uk> -->
https://www.wofeckcsclub.co.uk <https://www.wofeckcsclub.co.uk> -->
website loads
2. http://origin-www.wofeckcsclub.co.uk
<http://origin-www.wofeckcsclub.co.uk> -->
https://www.wofeckcsclub.co.uk <https://www.wofeckcsclub.co.uk> -->
website loads
3. http://www.wofeckcsclub.co.uk <http://www.wofeckcsclub.co.uk> -->
https://www.wofeckcsclub.co.uk <https://www.wofeckcsclub.co.uk> -->
website loads
4. http://www-test.wofeckcsclub.co.uk
<http://www-test.wofeckcsclub.co.uk> -->
https://www-test.wofeckcsclub.co.uk
<https://www-test.wofeckcsclub.co.uk> -->
https://www.wofeckcsclub.co.uk <https://www.wofeckcsclub.co.uk> -->
website loads
5. https://wofeckcsclub.co.uk <https://wofeckcsclub.co.uk> -->
https://www.wofeckcsclub.co.uk <https://www.wofeckcsclub.co.uk> -->
website loads
6. https://origin-www.wofeckcsclub.co.uk
<https://origin-www.wofeckcsclub.co.uk> -->
https://www.wofeckcsclub.co.uk <https://www.wofeckcsclub.co.uk> -->
website loads
7. https://www.wofeckcsclub.co.uk <https://www.wofeckcsclub.co.uk> -->
website loads
8. https://www-test.wofeckcsclub.co.uk
<https://www-test.wofeckcsclub.co.uk> -->
https://www.wofeckcsclub.co.uk <https://www.wofeckcsclub.co.uk> -->
website loads
On the whole, this is fine. I’d rather 1) and 4) had a single redirect
to https://www.wofeckcsclub.co.uk <https://www.wofeckcsclub.co.uk> but I
think this is a result of CloudFront first redirecting to HTTPS and then
the HTTPS site redirecting to the correct URI, so not sure I can do much
about this (except maybe enable CloudFront to communicate with the
origin via HTTP, and allow the HTTP origin site to redirect to the
correct URI).
However, a few of my websites do this instead:
1. http://savouredescapes.com <http://savouredescapes.com> -->
https://savouredescapes.com <https://savouredescapes.com> -->
https://www.savouredescapes.com <https://www.savouredescapes.com>
--> website loads
2. http://origin-www.savouredescapes.com
<http://origin-www.savouredescapes.com> -->
https://www.savouredescapes.com <https://www.savouredescapes.com>
--> website loads
3. http://www.savouredescapes.com <http://www.savouredescapes.com> -->
https://www.savouredescapes.com <https://www.savouredescapes.com>
--> website loads
4. http://www-test.savouredescapes.com
<http://www-test.savouredescapes.com> -->
https://www.savouredescapes.com <https://www.savouredescapes.com>
--> website loads
5. https://savouredescapes.com <https://savouredescapes.com> -->
https://www.savouredescapes.com <https://www.savouredescapes.com>
--> website loads
6. https://origin-www.savouredescapes.com
<https://origin-www.savouredescapes.com> --> website loads [not correct]
7. https://www.savouredescapes.com <https://www.savouredescapes.com>
--> website loads
8. https://www-test.savouredescapes.com
<https://www-test.savouredescapes.com> --> website loads [not correct]
For these websites, URIs 6) and 8) are not being redirected, and display
the website with the original URI in the browser. All the VirtualHosts
are configured the same, and look like this:
<VirtualHost *:80>
DocumentRoot /var/www/savouredescapes
ServerName www.savouredescapes.com
ServerAlias savouredescapes.com origin-www.savouredescapes.com
www-test.savouredescapes.com
<Directory /var/www/savouredescapes/>
AllowOverride All
</Directory>
ErrorDocument 403 /error/noindex.html
ErrorLog ${APACHE_LOG_DIR}/savouredescapes-error.log
CustomLog ${APACHE_LOG_DIR}/savouredescapes-access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =savouredescapes.com [OR]
RewriteCond %{SERVER_NAME} =origin-www.savouredescapes.com [OR]
RewriteCond %{SERVER_NAME} =www.savouredescapes.com [OR]
RewriteCond %{SERVER_NAME} =www-test.savouredescapes.com
RewriteRule ^ https://www.savouredescapes.com%{REQUEST_URI}
[END,NE,R=permanent]
</VirtualHost>
As far as I can tell, a URI like https://origin-www.savouredescapes.com
<https://origin-www.savouredescapes.com> */should/* be hitting my VPS
direct (no CloudFront, DNS points to my VPS) and getting redirected to
https://www.savouredescapes.com <https://www.savouredescapes.com>, which
should then be served via CloudFront. However, Apache doesn’t seem to be
performing this redirect. In the Apache logs, I see entries like this in
the ‘access’ log:
188.166.109.207 - - [09/Jul/2022:11:19:04 +0100] "GET / HTTP/1.1" 200
58957 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Firefox/102.0"
As opposed to something like this when the redirect does work:
188.166.109.207 - - [09/Jul/2022:11:11:18 +0100] "GET / HTTP/1.1" 301
568 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Firefox/102.0"
And nothing in the error logs. So I’m not sure how to troubleshoot
further */why/* the redirects aren’t working as expected for this
particular website.
In addition, because this */does/* work on some of my other sites (like
the https://www.wofeckcsclub.co.uk <https://www.wofeckcsclub.co.uk> site
I first showed the results for), I presume WordPress (or something
else?!?) must be doing an internal redirect, rather than Apache? Again,
as far as I can tell the WordPress configurations are the same; there
are no obvious plugins that would configure 301/302 redirects on the
WordPress instances that do work, although that’s not to say such a
plugin hasn’t been installed and configured in the past and since
removed, leaving the configuration running on the WordPress site…?
I’m wondering if anyone on this list has any relevant WordPress
experience, and any suggestions for files/configurations to check in
WordPress to see where these redirects might be happening? Also more
than happy to explore the fact that my Apache configuration could be
wrong and need tuning, and open to any other suggestions to try and
‘fix’ these redirects one way or another (the main thing I want is
consistency across all of them!).
Many thanks in advance,
Paul
_______________________________________________
BitFolk Users mailing list <users(a)mailman.bitfolk.com>
You're subscribed as <hobson42(a)gmail.com>
Unsubscribe:
<https://mailman.bitfolk.com/mailman/postorius/lists/users.mailman.bitfolk.com/>
or send an email to <users-leave(a)mailman.bitfolk.com>
--
Ian Hobson
Tel (+66) 626 544 695
1:56 p.m.
As an aside, if there's no vhost on the server that is http-only
(i.e. they all redirect to https) then I would just stop listening
on port 80 and dispense with every http vhost. You will clearly need
to switch to DNS-based Let's Encrypt challenges then, though.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
10 Jul
10 Jul
3:47 p.m.
As an alternative to DNS challenges, I’ve found TLS-ALPN challenges using
https://httpd.apache.org/docs/trunk/mod/mod_md.html to work well in that situation (and
seems to be less fiddly than cert-bot).
Joseph
On 9 Jul 2022, at 14:56, Andy Smith via BitFolk Users
<users(a)mailman.bitfolk.com> wrote:
As an aside, if there's no vhost on the server that is http-only
(i.e. they all redirect to https) then I would just stop listening
on port 80 and dispense with every http vhost. You will clearly need
to switch to DNS-based Let's Encrypt challenges then, though.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
BitFolk Users mailing list <users(a)mailman.bitfolk.com>
You're subscribed as <joseph(a)heenan.me.uk>
Unsubscribe:
<https://mailman.bitfolk.com/mailman/postorius/lists/users.mailman.bitfolk.com/>
or send an email to <users-leave(a)mailman.bitfolk.com>
6:40 p.m.
On Sat, Jul 9, 2022 at 2:56 PM Andy Smith via BitFolk Users <
users(a)mailman.bitfolk.com> wrote:
As an aside, if there's no vhost on the server
that is http-only
(i.e. they all redirect to https) then I would just stop listening
on port 80 and dispense with every http vhost. You will clearly need
to switch to DNS-based Let's Encrypt challenges then, though.
file validation has gone away for wildcard and multi-san certs anyway, so
you might as well migrate to dns validation where possible anyway. it's
very straightforward and very automatable.
-n
11 Jul
11 Jul
5:35 a.m.
Paul Lewis said:
I run several WordPress sites on my Bitfolk VPS, and I
have AWS CloudFront
in front of them.
With apologies for not helping with the actual question..
.. why involve AWS CloudFront?
A VPS is easily capable of running several dozen WP sites, provided you
avoid the 'front page of Slashdot' effect. Another 'similar to Bitfolk'
one
has a couple as well as a busy (hundreds of messages posted a day) forum
with no problems.
The example site could be easily made static via a plugin = even less
server load.
Unless you are running really busy sites such that the VPS often struggles
or actually get denial of service attacks, I can't see the value in the
extra hassle and expense.
Ian
8:56 a.m.
...or you could switch from Wordpress to the vastly better Modx
Iain
On 11 Jul 2022 at 6:43 am, Ian via BitFolk Users <users(a)mailman.bitfolk.com>
wrote:
Paul Lewis said:
_______________________________________________
BitFolk Users mailing list <users(a)mailman.bitfolk.com>
You're subscribed as <iain(a)hairydog.co.uk>
Unsubscribe:
<https://mailman.bitfolk.com/mailman/postorius/lists/users.mailman.bitfolk.com/>
or send an email to <users-leave(a)mailman.bitfolk.com>
I run several WordPress sites on my Bitfolk VPS, and I have AWS CloudFront in front of
them.
With apologies for not helping with the actual question..
.. why involve AWS CloudFront?
A VPS is easily capable of running several dozen WP sites, provided you avoid the
'front page of Slashdot' effect. Another 'similar to Bitfolk' one has a
couple as well as a busy (hundreds of messages posted a day) forum with no problems.
The example site could be easily made static via a plugin = even less server load.
Unless you are running really busy sites such that the VPS often struggles or actually
get denial of service attacks, I can't see the value in the extra hassle and expense.
Ian
1:28 p.m.
Seems we have all had our say on unrelated things we think should
be changed 😀 but my conclusion remains that the difference must lie
in the Wordpress config, as the redirect for even the sites that
work is here being done by Wordpress. I'd be interested to know if
you ever get to the bottom of this.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
894
days inactive
896
days old
10 comments
8 participants
participants (8)
-
Andy Smith -
Gavin Westwood -
iain -
Ian -
Ian Hobson -
Joseph Heenan -
Paul Lewis -
William Anderson