I've got an apache running wordpress on port 90. I've put a varnish cache in front of it and am running varnish on port 80.
I'm using the 4.0 vcl from here: https://github.com/nicolargo/varnish-nginx-wordpress/blob/master/varnish/varnish4-wordpress
When I request my site on :80 I get 301 redirected to :90 ... Surely that's not the point of varnish? How do I avoid this and stay on :80??
I'm a complete newbie to varnish / vcl so I unfortunately have no idea what to look for. I'm sure it's in the VCL though :)
Related post (but not answer on here either): Why is Varnish redirecting as 301?
It is surely not in VCL. However, do note that it's much better to start building from the provided default.vcl, adding bits by bits, to understand how it works.
As for why it doesn't work and ways to fix it.
Different ports (duh).
Option #1. Tell your PHP what the real port is.
Perhaps, the most easy fix would be to edit wp-config.php and tell the Wordpress where the request really came from. Add at the top of the file right after <?php:
$_SERVER['SERVER_PORT'] = 80;
Option #2. Just use the same ports.
You can actually use same port number(!) in both Varnish and Apache. Simply bind Varnish and Apache onto different interfaces, but same port numbers. To a Linux machine those are different ports, and there is no issue using same port number.
So Apache will have:
Listen 127.0.0.1:80
Varnish will have in the VCL:
backend default {
.host = "127.0.0.1";
.port = "80";
}
Option #3. Don't use Apache. Nginx to the rescue.
A not so easy fix perhaps would be switching to Nginx which can easily circumvent the "port in redirection" problem via simply one line of configuration:
port_in_redirect off;
Wordpress base URLs.
If the Wordpress site URL (in wp-admin) is set to include port number, then naturally that's where it will redirect you. No port number should be present in Wordpress site URL.
Bonus Tip: Fix Wordpress Jetpack in Varnish.
Related
I have a Windows PC with some Flask webapps running on various ports 5000, 5001, ...
I have mapped subdomains with CNAMEs to point to the server and Nginx handles the rerouting (correct wording?) to the appropriate ports: x.server.net -> ip:5000, y.server.net -> ip:5001
It works
Now I want to enable https so I would like to redirect users from http to https.
Further, I discovered that Nginx doesn't handle when users supply a non-standard port, so x.server.net:5001 actually points to the wrong Flask app. So I would also like to redirect non-default ports to the default (80 or 443 depending on http or https). Some of the apps don't need https, so I might mix it.
Can this be done with Nginx or should I use something else? I found others asking this, but the replies are only for Linux as far as I understand (iptables?).
And last but not least, is redirects a safe approach? Can it be ignored by a malicious client?
i have installed wordpress and i've set SSL (LetsEncrypt).
It works fine since few months.
Now i want to add Varnish to speed up site and i have one issue.
My config is:
MyPage.com (443) -> Varnish (80) -> MyPage (8080) no https.
When i open page, everything is OK
besides address to static files.
All URL's to CSS, JS, Images are served as HTTP, NOT HTTPS.
That is because in the end page is served by Apache without SSL.
Do you know how to change address to static files, that they will be served as HTTPS (https://MyPage.com/my.js instead of http://MyPage.com/my.js)?
Wordpress save the links absolutly in the database.
Soloution 1:
You edit all entries in the Database
Soloution 2:
Simple use this Plugin to write all url´s in the database from http to https:
https://de.wordpress.org/plugins/really-simple-ssl/
You might need to make sure the X-Forwarded-Proto header is set and passed all the way back through Varnish to the backend.
Assuming you have Apache:443 -> Varnish:80 -> Backend:8080
Then in the Apache config that is handling the https add the following to the VirtualHost
RequestHeader set X-Forwarded-Proto "https"
Varnish should forward this by default, unless you have done anything custom to the config that might prevent it.
This header should then be respected and used to set the protocol on the urls for assets.
we have activated HTTP Strict Transport Security in production. It works well. But now, when wanting to use a subdomain to develop, the website is automatically redirected to https:
https://dev.tokeeen.com/app_dev.php/my-habits
Event if the host is set to 127.0.0.1
127.0.0.1 dev.tokeeen.com
Is there something to avoid this behavior? Of course I don't want to force the host for the main domain.
You are currently setting this on your main site:
Strict-Transport-Security max-age=63072000; includeSubDomain
If you change this to remove the includeSubDomain bit then it will only apply to your top level domain and not the dev sub domain:
Strict-Transport-Security max-age=63072000;
You then need to visit your production site to load this header and overwrite the existing one in your browser’s cache.
However this is less secure (for example someone could set up www.tokeeen.com and pretend to be your site with a bit of DNS manipulation for example).
But to be honest you should just use https on you’re dev site. The Internet is moving towards HTTPS and many new features do not work under plain HTTP. Additionally what you are developing is not similar to your production site so if you include http:// links instead of https:// for example you’ll suddenly see this failing when you release to production.
You look to use LetsEncrypt on your site so the cert is free. Do yourself a favour and just get another free one for your dev subdomain.
You have to get yourself a wildcard certificate as the ssl certificate is only for that domain. That's the whole point of having a secure site.
I'm not sure what server system you are using but in case you don't want to use wildcards and are ok with less secure, you can bind the other domains to
port 80 with the binding type http`
I've set up VPS with Ubuntu 14.04 and Apache.
I set up a single vhost and installed WordPress.
All very straightforward with nothing unconventional.
The only settings in my .htaccess come from setting permalinks to be the names of the posts.
That configuration works with no issues.
Then I installed varnish from the repos.
I configured Apache to listen on port 8080. I set the vhost to respond to requests on port 8080. Varnish listens on port 80 before communicating with Apache on 8080.
After configuring that I restarted both Apache and Varnish.
And things work!
... almost!
The one single thing that doesn't work is this: requests for http://example.com/wp-admin return a redirect loop. Eventually the browser shows an error.
Every other route seems to succeed. Including routes to non-existent resources, which return WordPress's 404 page.
What does work are requests to http://example.com/wp-admin/index.php.
Other than configuring ports I haven't touched Varnish. I have no plugins for the WordPress site.
My default.vcl looks like this:
https://gist.github.com/anonymous/9c204c826c3bf4b7c2e167a241fc3dad
What could I be doing wrong?
For development, I'd like to serve multiple projects on different local domains, all on port 80. In my hosts file I direct local.example.com to localhost, same for local.example2.com.
Now I'm trying to convince nginx to serve the example resources for the one url, and the example2 resources for the other.
I've read the nginx documentation and this blog post. But I think I must be missing something.
I've added to my nginx.conf:
include /Users/iwein/Sites/conf/*.conf;
Then in sites I add configuration like example.conf:
server {
listen 80;
server_name local.example.com;
…
and example2.conf:
server {
listen 80;
server_name local.example2.com;
…
Now the weird thing is that nginx seems to load the alphabetically first config, but on the second url, it serves the resources from the first server definition too. Nginx seems to totally ignore the server_name. How should I configure for this use case?
UPDATE:
It appears that if you use only one separator in the domain name (e.g. example1.local), it works just fine. I didn't further pursue this, because I have better things to do, but it's odd.
Apparently, nginx doesn't like the format of my server names. If I remove the 'local' subdomain it seems to work much better. I'm now working with example.dev and example2.dev and the problem is gone.