@nkuehn thanks for report. What is the content of your config.ini.php | grep trusted_host ?

Is the hostname in the trusted_hosts?
Maybe the IP address is first in the list of trusted_hosts ?

Matthieu,

sure, could have included that in the first place. Heres's the setup:

• runs "bare iron" (no virtual machines involved) on a host with the root IP 46.4.59.18 (reverse DNS entry is not piwik, but the name we gave the physical machine as it runs other services, too)
• accessed via a DNS name (piwik.excentos.com) that points to the same address (no second IP)
• that IP is also the one that's written into the emails.
• running in an PHP5-FPM pool behind nginx on the local machine.
  * less config.ini.php | grep trusted_hosts -> trusted_hosts[] = "piwik.excentos.com" (entered via conf settings page)

what looks bogus to me is the fact that the trusted_hosts value is not an array. But: it works (I don't get the "untrusted hostname" warning when logging in to the piwik interface)

Can you run SQL query and what is the result?

SELECT * FROM piwik_option WHERE option_name = 'piwikUrl';

sure:

mysql> SELECT * FROM piwik_option WHERE option_name = 'piwikUrl';
+-------------+---------------------+----------+
| option_name | option_value        | autoload |
+-------------+---------------------+----------+
| piwikUrl    | https://46.4.59.18/ |        1 |
+-------------+---------------------+----------+
1 row in set (0.01 sec)

mysql>

See also

#5288 Sparklines fail to load behind reverse proxy because of wrong URI

#5290: Login leads to wrong URL when using ssl proxy

Adding guesswork:

• Sparklines fail to load behind reverse proxy because of wrong URI #5288 (sparklines path) may be related, but it seems to be just a path issue, not a root URL issue if I look at the screenshots)
• Login leads to wrong URL when using ssl proxy #5290 sounds entirely different to me, that's about redirects after login.

I tried a search for "piwikUrl" in the github codebase, but couldn't see where the value is written into the database. I can imagine that the value is written at installation time (install wizard), but I installed this piwik installation directly on the real domain. (can't access it via IP adress because it's a name based server in nginx).

argh, it gets even weirder: today in the early morning I received two "weekly" reports for the same website:

• one for the week before the last week (05/26->06/01) with the correct URL including https in the paths to logo etc.
• one for the last week (06/02->06/08) with the wrong URL (IP address).

The piwikUrl in the database is still the IP address.

Any ideas where to start researching?

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.

Hi @nkuehn - do you still experience this issue in Piwik 3.1.0 ?

Hi @mattab I am working in a different company for a while already and don't have an up to date setup available any more (and have no status and access to the one that we experienced this issue in). Sorry to say I can't help you out at the moment (don't have the spare private time any more too unfortunately).

If nobody else has come up with the issue since 2014 I personally would consider it irrelevant no matter if fixed or not.

But in any case I can recommend to test solely via an SSL-terminating reverse proxy and do not give the test runner direct access to the PHP IP / Host at all.

@mattab Are you forwarding from NGINX using localhost:someport?

I ask because we had this issue when I used proxy_pass http://localhost:someport but identifying the virtual host proxy_pass http://somepiwik.somedomain.tld:someport fixed the HTML email reports.

@krispii that could well be the reason but is a weird setup - you "hide" behind a reverse proxy to not make the internal URL / IP / Hostname accessible to the outside - proxying to the public external hostname is not the point of a proxy - you want to decouple internal deployment from external URL.

This might be a duplicate of #11545 but need to check. We'll try to fix it soon

Maybe this was fixed in #13122 ?

Please reopen if you still experience the issue with the latest Matomo @nkuehn

+1 - I don't even have a working installation any more so it's fair to assume if nobody else has the issue it does not exist any more.