Can't connect to docker container after set up

Greetings forum fiends,

I am VERY new to sysadminning on my local machine and am trying to set up nextcloud to run on docker with caddy.

The current issue I face is that while caddy can access and ping the nextcloud container on the docker network, any web requests just simply do nothing.

When trying to connect directly to the nextcloud container I time out with a 504.

I have tried juggling around the ports in the container, and while caddy does pick that up it is denied access to it.

I apologize if this a REALLY stupid issue but I have tried to provide all relevant files below.

Any help would be greatly appreciated, even if its a redirect to a different forum or issue that is more relevant.

docker-compose for nextcloud
version: '3'

    image: mariadb
    container_name: nextcloud-db
    hostname: nextcloud-db
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW --innodb_read_only_compressed=OFF
    restart: unless-stopped
    env_file: .env
      - ./nextcloud_data_db:/var/lib/mysql

    image: redis:alpine
    container_name: nextcloud-redis
    hostname: nextcloud-redis
    restart: unless-stopped

    image: nextcloud:fpm-alpine
    container_name: nextcloud-app
    hostname: nextcloud-app
    restart: unless-stopped
    env_file: .env
      - nextcloud-db
      - nextcloud-redis
      - ./nextcloud_data/:/var/www/html

    image: nginx:alpine
    container_name: nextcloud-web
    hostname: nextcloud-web
    restart: unless-stopped
      - ./nextcloud_data/:/var/www/html:ro
      - ./nginx.conf:/etc/nginx/nginx.conf:ro 
      - "80"
    name: caddy_net
    external: true
.env file for nextcloud



worker_processes auto;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/;

events {
    worker_connections  1024;

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    # Prevent nginx HTTP Server Detection
    server_tokens   off;

    keepalive_timeout  65;

    #gzip  on;

    upstream php-handler {
        server nextcloud-app:9000;

    server {
        listen 80;

        # HSTS settings
        # WARNING: Only add the preload option once you read about
        # the consequences in This option
        # will add the domain to a hardcoded list that is shipped
        # in all major browsers and getting removed from this list
        # could take several months.
        #add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;

        # set max upload size
        client_max_body_size 512M;
        fastcgi_buffers 64 4K;

        # Enable gzip but do not remove ETag headers
        gzip on;
        gzip_vary on;
        gzip_comp_level 4;
        gzip_min_length 256;
        gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
        gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/ application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

        # Pagespeed is not supported by Nextcloud, so if your server is built
        # with the `ngx_pagespeed` module, uncomment this line to disable it.
        #pagespeed off;

        # HTTP response headers borrowed from Nextcloud `.htaccess`
        add_header Referrer-Policy                      "no-referrer"   always;
        add_header X-Content-Type-Options               "nosniff"       always;
        add_header X-Download-Options                   "noopen"        always;
        add_header X-Frame-Options                      "SAMEORIGIN"    always;
        add_header X-Permitted-Cross-Domain-Policies    "none"          always;
        add_header X-Robots-Tag                         "none"          always;
        add_header X-XSS-Protection                     "1; mode=block" always;

        # Remove X-Powered-By, which is an information leak
        fastcgi_hide_header X-Powered-By;

        # Path to the root of your installation
        root /var/www/html;

        # Specify how to handle directories -- specifying `/index.php$request_uri`
        # here as the fallback means that Nginx always exhibits the desired behaviour
        # when a client requests a path that corresponds to a directory that exists
        # on the server. In particular, if that directory contains an index.php file,
        # that file is correctly served; if it doesn't, then the request is passed to
        # the front-end controller. This consistent behaviour means that we don't need
        # to specify custom rules for certain paths (e.g. images and other assets,
        # `/updater`, `/ocm-provider`, `/ocs-provider`), and thus
        # `try_files $uri $uri/ /index.php$request_uri`
        # always provides the desired behaviour.
        index index.php index.html /index.php$request_uri;

        # Rule borrowed from `.htaccess` to handle Microsoft DAV clients
        location = / {
            if ( $http_user_agent ~ ^DavClnt ) {
                return 302 /remote.php/webdav/$is_args$args;

        location = /robots.txt {
            allow all;
            log_not_found off;
            access_log off;

        # Make a regex exception for `/.well-known` so that clients can still
        # access it despite the existence of the regex rule
        # `location ~ /(\.|autotest|...)` which would otherwise handle requests
        # for `/.well-known`.
        location ^~ /.well-known {
            # The rules in this block are an adaptation of the rules
            # in `.htaccess` that concern `/.well-known`.

            location = /.well-known/carddav { return 301 /remote.php/dav/; }
            location = /.well-known/caldav  { return 301 /remote.php/dav/; }

            location /.well-known/acme-challenge    { try_files $uri $uri/ =404; }
            location /.well-known/pki-validation    { try_files $uri $uri/ =404; }

            # Let Nextcloud's API for `/.well-known` URIs handle all other
            # requests by passing them to the front-end controller.
            return 301 /index.php$request_uri;

        # Rules borrowed from `.htaccess` to hide certain paths from clients
        location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/)  { return 404; }
        location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console)                { return 404; }

        # Ensure this block, which passes PHP files to the PHP process, is above the blocks
        # which handle static assets (as seen below). If this block is not declared first,
        # then Nginx will encounter an infinite rewriting loop when it prepends `/index.php`
        # to the URI, resulting in a HTTP 500 error response.
        location ~ \.php(?:$|/) {
            # Required for legacy support
            rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;

            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            set $path_info $fastcgi_path_info;

            try_files $fastcgi_script_name =404;

            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $path_info;
            #fastcgi_param HTTPS on;

            fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
            fastcgi_param front_controller_active true;     # Enable pretty urls
            fastcgi_pass php-handler;

            fastcgi_intercept_errors on;
            fastcgi_request_buffering off;

        location ~ \.(?:css|js|svg|gif)$ {
            try_files $uri /index.php$request_uri;
            expires 6M;         # Cache-Control policy borrowed from `.htaccess`
            access_log off;     # Optional: Don't log access to assets

        location ~ \.woff2?$ {
            try_files $uri /index.php$request_uri;
            expires 7d;         # Cache-Control policy borrowed from `.htaccess`
            access_log off;     # Optional: Don't log access to assets

        # Rule borrowed from `.htaccess`
        location /remote {
            return 301 /remote.php$request_uri;

        location / {
            try_files $uri $uri/ /index.php$request_uri;

caddy docker-compose

    image: caddy
    container_name: caddy
    hostname: caddy
    restart: unless-stopped
    env_file: .env
      - "80:80"
      - "443:443"
      - "443:443/udp"
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./caddy_config:/config
      - ./caddy_data:/data

    name: caddy_net
    external: true
    header Strict-Transport-Security max-age=31536000;
    redir /.well-known/carddav /remote.php/carddav 301
    redir /.well-known/caldav /remote.php/caldav 301
    redir /.well-known/webfinger /index.php/.well-known/webfinger 301
    redir /.well-known/nodeinfo /index.php/.well-known/nodeinfo 301
    reverse_proxy nextcloud-web:80

Hi @JWJ212. Welcome to the world of self-hosting and being a sysadmin. :slight_smile:

The current issue I face is that while caddy can access and ping the nextcloud container on the docker network, any web requests just simply do nothing.

When trying to connect directly to the nextcloud container I time out with a 504.

Any clues in the Docker log for the nextcloud-web container?

At the moment the way your network is set-up I don’t believe you’ll be able to test Nextcloud w/o Caddy being in the middle. So you’re troubleshooting several variables at once.

I might eliminate Caddy (for testing purposes) to confirm that the nextcloud-web container is fully operational and offering up a functioning Nextcloud instance. That way you’re not troubleshooting multiple variables at once.

You may need to finesse your current Compose a bit to accomplish this since you’re using a custom network and only using expose for 80. I’m not sure what your network topology looks like so not sure what IP address you’d use for testing access nor where you’d be connecting from. It’ll be different depending on whether your Docker host is, say, your workstation versus a remote server.

I like to be explicit when I’m binding a service to a port, so I might suggest something like this for your nextcloud-web (for testing):


Replacing with an IP address on your Docker and 8080 with any available port. The above would make reachable and should open up Nextcloud. Even if you get an error there from Nextcloud itself, that’ll be a step in the right direction.

Couple other notes:

[1] Alternatively you can use a hostname there in a not-fully-documented way, but it requires some extra steps that can only be done after installation rather than in the Compose file currently. For now leave it empty so that it doesn’t create a broken configuration at start-up. Or place the IP of your proxy in there if you know it.
[2] You should be able to replace the proxy and le-companion containers with caddy.