I've created a reverse proxy for webmin through nginx to run webmin at [site domain]/webmin instead of port 10000 ([site domain]:10000).

When I go to [site domain]/webmin, the login page shows up as you'd expect-- but when I try to login, the login page simply reloads (no error message, no success). The login page has all assets (images, js, etc.) properly loaded.

Looking at /var/webmin/miniserv.log, I'm seeing: - - [26/Jul/2015:14:07:13 -0400] "POST //session_login.cgi HTTP/1.0" 401 2892

Note the 401 (not authorized) error status.

Before I set up the reverse proxy, successful logins looked like this: - - [26/Jul/2015:13:34:38 -0400] "GET /admin/config/session_login.cgi HTTP/1.1" 401 2840 - root [26/Jul/2015:13:34:44 -0400] "POST /session_login.cgi HTTP/1.1" 200 871

My system auth log isn't getting pinged by the login attempts, so webmin isn't even making the login call via PEM (it's getting stopped before that).

Does anybody know what could explain this 401 error in my log, or more generally, what might be keeping webmin login from working?

Many thanks!

nginx config:

server {
        listen 443 ssl;
        server_name site.example.com;
        ssl on;

        ssl_certificate [ssl cert].crt;
        ssl_certificate_key [ssl key].key;
        ssl_protocols [ssl protocols];
        ssl_ciphers [ssl ciphers];

        location /webmin {
            proxy_redirect https://site.example.com/webmin/;
            proxy_set_header Host $host:$server_port;
  • For what its worth, my configuration is the same as serverfault.com/questions/443482/proxying-webmin-with-nginx (as is my problem, only this fix doesn't work for me). I also found this article helpful and have tried these suggestions: serverfault.com/questions/98987/…
    – BBB
    Commented Jul 26, 2015 at 18:35
  • If you look at your paths in the example you are giving, the problem appears to lie within the proxy itself. As a side note, this is a security risk that you are opening up. Make sure that you have secure usernames and hardened passwords and keep an eye on your Webmin log.
    – closetnoc
    Commented Jul 26, 2015 at 22:40
  • Thanks... I'll look more at the proxy, but any suggestions? I just posted the nginx code above for review. Thanks for the note on security... I think I'm good because webmin is behind an internal auth setup, uses good usernames and strong passwords, and two factor auth is enabled.
    – BBB
    Commented Jul 27, 2015 at 4:05
  • It has been over 12 years since I set-up a proxy- I am a semi-retired core network engineer for the major global telcom networks- still, I have probably forgotten much. I will look into your edits and see if I can find something. It might take me a while to poke around.
    – closetnoc
    Commented Jul 27, 2015 at 4:11
  • The only quick thing I see is that you may want to try removing the trailing slashes in your proxy settings such as proxy_redirect site.example.com/webmin and proxy_pass Your failed attempt had two // slashes. Worth a try.
    – closetnoc
    Commented Jul 27, 2015 at 4:16

2 Answers 2


Try this solution, it works for me well:


relative_redir=0   # pay attention on this



nginx config:

location /webmin/ { 
    proxy_pass http://localhost:10000/;

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Do not add proxy_set_header Host $host;, it won't work.

Webmin should be available on http://www.examle.com/webmin/


  • 1
    It appears there may be some typos. I am not sure if they are deliberate. Can you double check? Cheers!!
    – closetnoc
    Commented Jul 26, 2018 at 22:07

It sounds like your web browser is naturally caching the problematic login pages and/or the headers returned for the login pages are not correct.

Check the speed of the page load. When you login and press the login button, if the load time is ridiculously fast compared to the first time the login screen has loaded, then you know that the previous page was cached and then being reloaded.

To workaround this problem temporarily, configure your web browser to disable all forms of caching and turn on cookies.

There's also a possibility that cookie values were not used at the time the page is requested after successful login. This results in every user seeing the same content as a guest would.

If you want to go more technical, then look for HTTP headers on each request using an advanced command line tool like CURL or maybe webpagetest.org may help as well, especially with page timings. The most important header to look for is:


Once the login button is selected and the correct credentials are used, then the response that is returned back to the browser should come with HTTP headers that contain Set-Cookie to indicate a user is logged in so that the next time a page from the same site is loaded in the same browser, a cookie is sent to the server to indicate the user has already logged in before.

And if you want to increase the chances of server requests being logged from you, just turn off caching for a while and do your testing. You might see a few repeated entries, especially if your pages always contain the same image.

  • Thanks for the reply... good thought, but I don't think that's the issue I'm having. Used private browsing / incognito, and changed the url. It still didn't work. I checked cURL, and this is in the header:
    – BBB
    Commented Jul 27, 2015 at 4:10
  • Set-Cookie: testing=1; path=/; httpOnly
    – BBB
    Commented Jul 27, 2015 at 4:10
  • pragma: no-cache Expires: Thu, 1 Jan 1970 00:00:00 GMT
    – BBB
    Commented Jul 27, 2015 at 4:11
  • Cache-Control: no-store, no-cache, must-revalidate
    – BBB
    Commented Jul 27, 2015 at 4:11
  • Cache-Control: post-check=0, pre-check=0
    – BBB
    Commented Jul 27, 2015 at 4:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.