Campaign tabs not working / PHPList behind reverse-proxy

I am running PHPList 3.0.12. I have an Apache web server and an Nginx reverse proxy.

When I access it directly, it works. When I access it via the reverse proxy, it mostly works, but the campaign buttons do not function. It stays stuck on the 1st (default) tab.

After spending a lot of time on this I found the following:

  1. There is no issue viewing other tabs with a manually entered URL
  2. The browser does not send the full GET request. the ‘&tab=XXX’ is missing. In effect, the Nginx reverse-proxy (and Apache web server) is correctly responding to the request.
  3. This is the same whether I use Firefox or Chromium.

WHY the browser does not send the full URL when accessing this via the Nginx proxy - I have no idea. This is what I am seeking qualified feedback on. Thanks :smile:


I think you should make a bug report about this, you can find info on the developer home page



Thanks for the suggestion Anna. I have now submitted it as issue #17737

That isn’t what phplist is actually sending.
When you use the Next and Back buttons the browser sends a post with request url of the current tab. There is a form data field “followupto” that identifies the new tab. phplist then sends a redirect to the new tab.

I’m not too familiar with reverse proxies but possibly it is not configured to handle this set of requests.

That is not correct. I don’t know the inner details of PHPList so I only found this out by investigation and observation and when it works it does send ‘&tab=xxx’ in the GET request.

There is nothing wrong with the reverse proxy. It handles plenty of POST requests elsewhere and even with very generous config variables - PHPList is the only application with problems.

Maybe we are looking at different things but this is a screen shot using Firefox web console of the POST when moving from the Attach tab to the Format tab

That is followed by a GET for the Format tab

You seemed to say that phplist works when not using the reverse-proxy, and does not work when the reverse proxy is used. So the main difference is the reverse proxy itself.

Following is the GET variables at the relevant page:

Directly at Apache
Array ( [page] => send [id] => 51 [tk] => 514f0ddbbd6959a [tab] => Format [pi] => )

With reverse proxy
Array ( [page] => send [id] => 51 [tk] => e937dc1e6cbc49ba761c34c [pi] => )

If I add “&tab=Format” to the URL (by hand) it works.

Hey @nettrustnz are you the same as “hedrickbt” on mantis/github?


Ah wait, no I can see that’s not you now. So, we will be thanking you for your contribution in the release notes for the next version, we will link to your profile - could you spruce it up a little maybe? Nice avatar, bit more info :wink:

What Avatar? That’s the default. What release notes? Last I heard it had reached stalemate.

After beating my head against a brick wall several times and then being pitched to pay to fix the problem, I gave up on the discussion. I was willing to help fix the problem but your bugs manager said I’d have to fork the project. How ridiculous is that?

It seems ironic to me that this project codes for no-javascript compatibility but not for reverse proxy setup. I’d suggest forgetting outdated philosophies and spending the time coding for modern systems.

I have spent some more time on it and fixed the issue. The issue is detailed at

I have not included code as my coding style differs from the PHPList authors, but in short - public_html/lists/admin/lib.php (around line 920) has a PHP variable $_SERVER[“HTTP_HOST”] which needs to be replaced with the host name or a variable referencing this - of the front end (user facing) hostname in a reverse proxy setup.

If you go to and edit your profile there you can add any image you want as an avatar.

Yep, you can see phpList 4 under way on github

Good stuff :smile:

It’s not resolved despite it being marked as such.

There really isn’t much point in me spending the time testing it to then find I can’t provide feedback because it’s “resolved”, which it isn’t at this point.


sorry it was marked resolved so quickly, this was because of the new version we are releasing, which we were going to to do on Monday. It needed to be marked resolved to go in the new version we wrapped up.

We have decided, however, to allow an additional month for more work and feedback etc (we are working on making our development more collaborative). I just opened up the issue again for you to give feedback, which is welcome.

Please do understand that we have given your issue a disproportionate and unusual amount of time, especially considering it’s quite a specific issue, and the development team for phpList is small. Our developers may sometimes be a bit blunt, but they are providing you with this support free of charge and they are also very overstretched right now. Additionally, when the developer said “fork the project” he meant on github, so you can fix the code and make a pull request, which is our normal development process, if you look at

Kind Regards

phpList community manager