As this will -thanks to me being quite clueless- be a very open question I will start with the setup:

One nginx server on an old Raspi getting ports 80 and 443 routed from the access point and serving several pages as well as some reverse proxies for other sevices.

So a (very simplified) nginx server-block that looks like this:

# serve stuff internally (without a hostname) via http
server {
	listen 80 default_server;
	http2 on;
	server_name _; 
	location / {
		proxy_pass http://localhost:5555/;
                \# that's where all actual stuff is located
	}
}
# reroute http traffic with hostname to https
server {
	listen 80;
	http2 on;
	server_name server_a.bla;
	location / {
		return 301 https://$host$request_uri;
	}
}
server {
	listen 443 ssl default_server;
	http2 on;
	server_name server_a.bla;
   	ssl_certificate     A_fullchain.pem;
    	ssl_certificate_key A_privkey.pem;
	location / {
		proxy_pass http://localhost:5555/;
	}
}
#actual content here...
server {
	listen 5555;
	http2 on;
    	root /srv/http;
	location / {
        	index index.html;
   	} 
    	location = /page1 {
		return 301 page1.html;
	}
    	location = /page2 {
		return 301 page2.html;
	}
        #reverse proxy for an example webdav server 
	location /dav/ {
		proxy_pass        http://localhost:6666/;
	}
}

Which works well.

And intuitively it looked like putting Anubis into the chain should be simple. Just point the proxy_pass (and the required headers) in the “port 443”-section to Anubis and set it to pass along to localhost:5555 again.

Which really worked just as expected… but only for server_a.bla, server_a.bla/page1 or server_a.bla/page2.

server_a.bla/dav just hangs and hangs, to then time out, seemingly trying to open server_a.bla:6666/dav.

So long story short…

How does proxy_pass actually work that the first setup works, yet the second breaks? How does a call for localhost:6666 (already behind earlier proxy passes in both cases) somehow end up querying the hostname instead?

And what do I need to configure -or what information/header do I need to pass on- to keep the internal communication intact?

  • Matt The Horwood@lemmy.horwood.cloud
    link
    fedilink
    English
    arrow-up
    2
    ·
    12 hours ago

    Looking at the docs, you need the external server config for Anubis. Then where Anubis will hand back good traffic destined for your application, you did read the docs right?

    • Ooops@feddit.orgOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      5 hours ago

      More than once. But -not actually surprsing by a work in progress by mostly one single person- it’s not actually what I would call well-structured or even coherent. 😅

      More than once googled for a detail I didn’t understand and ended up on the issue tracker realizing I’m not alone and some behavior is indeed illogical or erratic.

      And then some of it is of course referencing forwarding- and header-information, how it’s handled, where it’s flattened… and as my question should have told you, I don’t even much clue how it is handled normally.

        • Ooops@feddit.orgOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          4 hours ago

          And to give you a reference to some of the details glossed over…

          The anubis instance listening to a socket doesn’t work as described there. Because the systemd service is running as root by default but your web server would need access to the socket. So you first need to harmonise the user the anubis service runs as with the one from your web server with the permissions of the /run/anubis directory.

          (see Discussion here for example)

          Also having one single setup example in the docs with unix sockets when that isn’t even the default is strange in the first place…

          Half the Environmental Variables are just vaguely describing what they do without actual context. It probably makes perfect sense when you know it all and are writing a description. But as documentation for third-person use that’s not sufficient.

          Oh, and the example setup for caddy is nonsensical. It shows you how to route traffic to Anubis and then stops… and references Apache and Nginx setups to get an idea how to continue (read: understand that you then need a second caddy instance to receive the traffic…).

          PS: All that criticsm reads harsher than it is meant to be. Good documentation needs user input and multiple view points to realize where the gaps are. That’s simply not going to happen with mostly one person.

  • moonpiedumplings@programming.dev
    link
    fedilink
    English
    arrow-up
    3
    ·
    14 hours ago

    I don’t think anubis can proxy webdav. So that breaks.

    Instead of putting anubus at 443, put it at the port 80 block. Or at the 5555 block.

    What you probably need to do is make it so that webdav traffic isn’t proxied through anubis.

    • Ooops@feddit.orgOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      5 hours ago

      It isn’t webdav per se. It’s the website presented by a webdav server. So there should be no functional difference between this and yet another webserver in a decentralized setup.

      Yes I know that I can easily change things around to have the reverse proxy run ignored. I was more interested in the “why it happens” than a practical solution (for that I could just move the reverse proxy one block up…).

  • Decronym@lemmy.decronym.xyzB
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    4 hours ago

    Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

    Fewer Letters More Letters
    HTTP Hypertext Transfer Protocol, the Web
    IP Internet Protocol
    nginx Popular HTTP server

    2 acronyms in this thread; the most compressed thread commented on today has 17 acronyms.

    [Thread #229 for this comm, first seen 10th Apr 2026, 06:40] [FAQ] [Full list] [Contact] [Source code]

    • Ooops@feddit.orgOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      14 hours ago

      Logs of what exactly? I don’t even know where to look. Neither is nginx logging an error, nor is a request ending on an unavailable port and just timing out logged anywhere. How would I set up extensive logging of anything but errors and accesses?

      As far as I’m concerned this is not some error but something regarding the details how proxy_pass works, that I don’t understand.

      In fact it isn’t even an actual problem per se. I can easily move the reverse proxy up one block so only the actual pages are protected. But the point is that I want to understand why a request that should be routed internally (and is without Anubis in the mix) ends up there. I would suspect some way the default headers are transmitted screwing things up.

  • SavvyWolf@pawb.social
    link
    fedilink
    English
    arrow-up
    1
    ·
    19 hours ago

    I’m not sure if it’s treating “localhost” as a hostname or not, but does replacing it with 127.0.0.1 function as expected?

    • Ooops@feddit.orgOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      19 hours ago

      I have tried localhost and 127.0.0.1 after initially using the internal 192.168.x.x IP and the behavior is always identical.