I'm trying to run Matomo behing a reverse proxy. I followed the https://matomo.org/faq/how-to-install/faq_98/ , but there are still some issues left. For example, the MultiSites plugin/All websites page links are broken.
I expect the links to the websites to work. They don't. When I pick the website from the dropdown in the CoreHome, it work flawlessly.
Incorrect in MultiSites:
Correct in CoreHome:
Fix the urls in the MultiSites, so that they are either relative, or correctly absolute.
nginx reverse proxy conf:
location /matomo/ {
resolver 127.0.0.11 valid=30s;
set $upstream http://matomo:8100;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Referer $http_referer;
proxy_buffering off;
proxy_pass $upstream;
rewrite ^/matomo/(.*)$ /$1 break;
}
Something similar was also reported in #13627
I'm using Matomo within Docker. I can confirm this bug. I've the exact same behavior.
My nginx reverse proxy conf:
location /matomo/ {
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_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Uri /matomo/;
proxy_pass http://172.28.1.10/;
proxy_read_timeout 90;
}
config.ini.php
[General]
force_ssl = 1
assume_secure_protocol = 1
proxy_client_headers[] = "HTTP_X_FORWARDED_FOR"
proxy_host_headers[] = "HTTP_X_FORWARDED_HOST"
proxy_uri_header = 1
Any solution so far?
This issue occurs when the reverse proxy is setup with a directory that points at a Matomo instance, but the Matomo instance isnt actually installed in that directory. For example if the proxy Matomo url is mydomain.com/matomo
but Matomo is installed at someotherhost.com/
or someotherhost.com/somotherdirectory
If Matomo is installed in the same directory path (someotherhost.com/matomo
) as set in the reverse proxy (mydomain.com/matomo
) then this wouldn't be an issue.
In SettingsPiwik.php:198-201 there is a check that if the $currentUrl
does not match the $url
then the piwikUrl option is replaced by the $currentUrl
.
The $currentUrl
is being generated using Common::getCurrentScriptPath()
which builds the URL path based on the directory structure of the Matomo installation, which doesn't include the /matomo/ directory.
Disabling the check on lines SettingsPiwik:198-210 works around the problem and the piwikUrl is not overwritten.
We could add a new config.ini.php option force_current_url = "mydomain.com/matomo"
which when set could override generation of the $currentUrl
from the script path and simply use the provided value.
@tsteur Does this sound like an acceptable solution?
@bx80 I haven't tested but was hoping it might fix it by simply removing piwik.piwik_url
in
and in the sparklineImage
method?
Seems we usually don't use this and instead simply use relative links maybe
@tsteur Thanks, that worked on my docker / reverse proxy test setup, at least for some of the broken links (choose site and the sparkline), there might be a few other places that need adjusting too (add new website, etc).
I'll create a PR to replace any piwik_url usage in the multisites plugin with relative paths.
There is actually an existing config setting available in current releases which resolves this problem.
Adding proxy_uri_header = 1
to the [general]
section of config.ini.php will make sure the forwarded URI is used when generating links. I've tried it with the docker / reverse proxy test setup and it works.
Has this been fixed in 4.7.1?
Because I just updated my systems to 4.7.1 and the links to the websites do work now.
But not all the urls are correct yet. The logo image for example still points tohttps://mydomain.com/plugins/Modern/images/logo.svg?matomo
instead ofhttps://mydomain.com/matomo/plugins/Modern/images/logo.svg?matomo
That means the logo still won't show (same as in the screenshots above).
So I guess this has only been fixed partially... Can anyone confirm this?
Thanks for your work!
Hi @54mu3l, thanks for following this up.
I've tested this with 4.7.1 and the logo paths should be correct as long as the proxy_uri_header
config option is set.
Could you try adding proxy_uri_header = 1
to the [General]
section of your config/config.ini.php
file and see if that fixes your logo paths?
Hi @bx80, thanks for the hint. Now it seems to work!