Hi @ToBeReplaced thanks for the report. Do you also experience this issue: #6703 ?

The real-time map fails to work. However, I do not experience the same issue:

I see a failed request to https://www.example.com/plugins/UserCountryMap/svg/world.svg, which should be https://www.example.com/analytics/plugins/... in my case.

Sorry for the delay.

I am also experiencing this issue. When logging into Piwik using the URL:

https://www.ourwebsite.com/piwik/index.php

I am redirected to:

https://www.ourwebsite.com/

Which is causing some confusion and annoyance. When I press Back I am taken to the dashboard.

let's investigate this issue as part of the broader set of bugs in #6880 -> our goal will be to make Piwik work perfectly in this special use case which many users have reported issues with.

@ToBeReplaced Could you please document the rewrite you've used? Thanks in advance!

@patriiiiiiiiiick This is an extract of my nginx.conf. This is inside of a docker container that has host piwik mapped to another instance of nginx serving piwik on port 80. The configuration redirects all traffic to use TLS, but it communicates with piwik in the clear.

location = /analytics/index.php {
  limit_except GET POST {}
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Host $host;
  proxy_set_header Host $host;
  proxy_redirect https://www.example.com/index.php /analytics/index.php;
  proxy_pass http://piwik/index.php;}

location /analytics/ {
  limit_except GET POST {}
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Host $host;
  proxy_set_header Host $host;
  proxy_pass http://piwik/;}}}

In the piwik host:

location = / {
  return 301 https://www.example.com/analytics/index.php;}

location ~ [^/]\.php(/|$) {
  fastcgi_split_path_info ^(.+?\.php)(/.*)$;
  if (!-f $document_root$fastcgi_script_name) {
    return 404;}
  fastcgi_pass php:9000;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  include /etc/nginx/fastcgi_params;}}}

can you let us know the content of PHP $_SERVER? We kinda need it in order to fix this issue.

To get it, can you create a file like test.php in your Piwik directory and paste

<?php

var_export($_SERVER);

afterwards you can open this file by opening the URL https://yourdomain/test.php in the browser. Please remove this file afterwards again

I placed test.php and then requested https://www.example.com/analytics/test.php.

array (
  'USER' => 'apache',
  'HOME' => '/usr/share/httpd',
  'FCGI_ROLE' => 'RESPONDER',
  'SCRIPT_FILENAME' => '/etc/nginx/html/test.php',
  'QUERY_STRING' => '',
  'REQUEST_METHOD' => 'GET',
  'CONTENT_TYPE' => '',
  'CONTENT_LENGTH' => '',
  'SCRIPT_NAME' => '/test.php',
  'REQUEST_URI' => '/test.php',
  'DOCUMENT_URI' => '/test.php',
  'DOCUMENT_ROOT' => '/etc/nginx/html',
  'SERVER_PROTOCOL' => 'HTTP/1.0',
  'GATEWAY_INTERFACE' => 'CGI/1.1',
  'SERVER_SOFTWARE' => 'nginx/1.7.7',
  'REMOTE_ADDR' => scrubbed,
  'REMOTE_PORT' => '59901',
  'SERVER_ADDR' => scrubbed,
  'SERVER_PORT' => 80,
  'SERVER_NAME' => 'www.example.com',
  'REDIRECT_STATUS' => '200',
  'HTTP_X_FORWARDED_FOR' => scrubbed,
  'HTTP_X_FORWARDED_HOST' => 'www.example.com',
  'HTTP_HOST' => 'www.example.com',
  'HTTP_CONNECTION' => 'close',
  'HTTP_USER_AGENT' => 'curl/7.43.0',
  'HTTP_ACCEPT' => '*/*',
  'PHP_SELF' => '/test.php',
  'REQUEST_TIME_FLOAT' => 1446437222.2988,
  'REQUEST_TIME' => 1446437222
)

This is after my fancy rewrites as indicated above though, so it might not be particularly helpful. Notably, the "analytics" prefix is nowhere to be seen.

I don't know what you are planning, but for me, it would be great to specify a "url_prefix" in config.ini.php that defaults to /. While I can use the proxy server to perform rewrites on 3xx redirects, I can't use that to rewrite assets that are appearing in Piwik's html, like the logo.svg.

I might also be misunderstanding altogether now; This was a while back, and I haven't touched my installation since I first spun it up -- almost a year now!

I've got the exact same issue

Issue still exists, most likely because SettingPiwik::getPiwikUrl (with the help of URL::getCurrentScriptName) determines the URL wrong. There is even a DB option for "piwikUrl", but manually setting it to the correct URL is being overwritten immediately upon next request.
I wonder why there is no chance of explicitly setting the URL for a use case as demonstrated by @ToBeReplaced. I'm about to run a similar set-up (nginx reverse proxy) and have to look for workarounds now :-(

Edit, got one workaround to work successfully: Move Piwik in subfolder named identically to the path the reverse proxy is using, i.e. to /path/to/wwwroot/analytics/ instead of /path/to/wwwroot/.

nginx vhost conf of reverse proxy:

location /analytics/ {
    ...
    proxy_pass http://<piwik-host>:8081/analytics/;
    ...
}

nginx vhost conf for piwik:

root /path/to/wwwroot/;
...
location /analytics/ { 
   ... 
   try_files $uri /analytics/index.php?$query_string;
}

Thanks for posting your workaround @fhadlich

I could resolve the issue by patching the core/Url.php
The function getCurrentScriptName has an option to remove the PathInfo, which is set by default.
If $_SERVER['PATH_INFO'] is set but empty, the complete path is stripped off, which is wrong.

if ($removePathInfo && isset($_SERVER['PATH_INFO']) ) {
   $url = substr($url, 0, -strlen($_SERVER['PATH_INFO']));
}

I fixed it with an additional check:

if ($removePathInfo && isset($_SERVER['PATH_INFO']) && !empty($_SERVER['PATH_INFO'])) {
    $url = substr($url, 0, -strlen($_SERVER['PATH_INFO']));
}

a new pull request was submitted by @user121216 in #12011 and addresses this issue (by adding a new nginx setting for proxy_set_header X-Forwarded-Uri /subfolder_here; if you could test and leave a comment on the PR that would be great.

@mattab Thank you for the callback on this. I am unfortunately not in a position to test the PR. Hopefully another affected user will be able to chime in.

I can't locate/reproduce this issue now (I can't remember if we applied some of the workarounds above) and can't justify having it tested as the concerned instance is in phase out. I'll notify other people in case they can give it a try.

Hi everyone,

Since #12011 was merged, we consider this issue fixed. Please check the FAQ here for more information: https://piwik.org/faq/how-to-install/faq_98/

in particular check the section If Piwik is behind a reverse proxy and installed in a sub-path

Feedback welcome!

@mattab Can you look into the issue that @benjaminpesch posted about?
I don't have piwik/matomo behind a reverse proxy, but instead I'm rewriting the requests. Everything works correctly... well. Almost. Some paths and the logo are broken. The piwik.piwik_url is pointing to the on-disk directory name, not the one that is visible from the public.
(i.e., it's installed in /var/www/local-dir, whereas it's accessed via https://example.org/public-dir; the logo points to https://example.org/local-dir/..., which is wrong)

As @benjaminpesch pointed out, there is this code in Version 3.3.0:

if ($removePathInfo && isset($_SERVER['PATH_INFO']) ) {
   $url = substr($url, 0, -strlen($_SERVER['PATH_INFO']));
}

Before the if line, $url points to the public-dir, but then $url = substr($url, 0, -strlen($_SERVER['PATH_INFO'])); runs:
PATH_INFO is empty for me, so it results in substr($url, 0, 0). This results in $url getting cleared, so it's empty afterwards, and then it falls back to what comes below that code:

        /**
         * SCRIPT_NAME is our fallback, though it may not be set correctly
         *
         * @see http://php.net/manual/en/reserved.variables.php
         */
        if (empty($url)) {
            if (isset($_SERVER['SCRIPT_NAME'])) {
                $url = $_SERVER['SCRIPT_NAME'];
            } elseif (isset($_SERVER['SCRIPT_FILENAME'])) {
                $url = $_SERVER['SCRIPT_FILENAME'];
            } elseif (isset($_SERVER['argv'])) {
                $url = $_SERVER['argv'][0];
            }
        }

tl;dr: PATH_INFO is empty -> $url gets cleared -> $url is filled with a fallback path (inaccessible from the public) -> logo breaks, piwik.piwik_url has wrong value
This was not touched by #12011 and is still broken

Thanks @PotcFdk and @benjaminpesch for reporting this issue! I've opened this PR to address it: #12500
-> could you please test this small patch on your instance, and report on the PR if it's working for you? Thanks