NC returns internal error if connected through chain of 2 proxies via unix domain socket

Hello all

I have set of docker images (nextcloud, nginx, documentserver and mariadb) that run nextcloud, nginx and onlyoffice documenserver all together. The “nginx” server (let it call Nginx1) acts as an internal (“in-docker”) HTTP router. It distributes request between nextcloud and documetserver and communicates outside the docker cloud.

  • All containers are connexted to single internal docker network (called ‘nextcloud’).
  • The nextcloud docker image is latest fpm-alpine (now 15.0.2).
  • Internally all containers communicate through pure HTTP protocol.
  • Nginx1 exposes HTTP port for outside (out-docker) communication
  • All is started from single docker-compose.yaml.

I also have one more nginx server on the same host (call in Nginx2) , which acts as a HTTPS proxy (exposed to Internet) and in addition it serves another applications (outside the docker).

Everything works well if I use HTTP to interconnext Nginx1 and Nginx2. But I wanted to use unix socket to interconnect them (it should be approx. 5x faster then HTTP - at least in case redis and databases it is) and it does not work. Nextcloud returns “Internal server error” page on every request.
The unix domain socket is created in the docker’s Nginx1 and exposed to local filesystem.

When I looked into browser HTTP commucation log for the “index.php” page, it seems that all is OK, until browser requires the “/files” folder, to which request the server responds by HTTP status 500.
Nothing usable is in logs on every chain element (Nginx1, Nginx2 nor Nextcloud).

I am attaching site configuration for “Nginx2”

# nextcloud site
server {
        server_tokens off;
        client_max_body_size 10G;
        # SSL configuration (managed by Certbot)                                                                  
        listen [::]:443 ;
        listen 443 ;
        ssl_certificate /etc/letsencrypt/live/;
        ssl_certificate_key /etc/letsencrypt/live/;
        include /etc/letsencrypt/options-ssl-nginx.conf;
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
        ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

        location / {
#            proxy_pass http://unix:/run/nginx/nextcloud.sock;         # this does not work
            proxy_pass http://localhost:8042;                          # this works well
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;

I tried slightly tweak “proxy_pass” parameters, but without success. Also I did not find anything reasonable using Google. Can someone help me ?

It is of course possible to use only 1 proxy (the outside Nginx2), but in this case the nginx.conf will be much more complex and the solution looses it’s flexibility. And benefit of using unix socket is significant against network (even against localhost; mainly under heavy load).

Hi, that’s a nice setup you have here :+1:

I’m a little confused about this one.
Do you mean:

  • Nginx1 have the unix socket file shared in a volume that is mounted in both nginx containers.
  • nginx1 have its unix unix socket file mounted as a volume on the host’s file system AND nginx2 have this same folder/file from the host mounted as local volume.
    That last one may cause some troubles.
    Anyway a docker exec <nginx1-2> ls -l /run/nginx/nextcloud.sock wouldn’t hurt for troubleshooting. So you can check the perspective of all containers.

Nginx1 creates the docker in the directory, that is mounted from external - host - FS (now it is “/run/nginx” on both - container and host FS). Socket is visible on both ends, it has correct rights (so far 777 - to avoid permissions issue).

Nginx2 is not a container - it is installed directly on the host. But I tried Nginx2 also in the container with shared volume between them - the behavior is the same. Btw portion of communication between browser and nextcloud backend passes well, and the 500 (internal error) page originates also from nextcloud (with correct CSS, color … etc)

I continued in investigating and I found that some apps work well in configuration mentioned above (for example gallery, calendar ) and some do not (mainly files, bookmarks), some partially.

Ok thank you.
Sorry I assumed everything was in container.
One hypothesis could be nginx2/nextcloud failing in PHP when called by socket.
Have you checked the nextcloud’s logs for potential error, or even access ?
I looked for info on nginx to nginx via socket but I found no good info and almost no reasult about this kind of setup.
As last resort you can try to set logging to max verbosity on both nginx servers to see if an error pop out somewhere.
Sorry I’m not very helpfull :frowning_face:

Never mind, thank you for a discussion :slight_smile:
I’ve checked log (set nextcloud log level to 0 before), but nothing useful (only the sameinfo as in web browser’s log).
I didn’t do set higher log level on nginx so far so I’m going to try it.

Btw I also searched net before wrote here, but also didn’t find anything useful.