☰

問題 - アプリにアクセスしようとすると「404 - ファイルが見つかりません」というエラーが表示される (初回アクセス時も含む)

tag-icon • tag-icon docker nginx-reverse-proxy nextcloud
問題 - アプリにアクセスしようとすると「404 - ファイルが見つかりません」というエラーが表示される (初回アクセス時も含む)

問題 - アプリにアクセスしようとすると「404 - ファイルが見つかりません」というエラーが表示される (初回アクセス時も含む)

nextcloud.example.com 経由でブラウザでアプリにアクセスしようとすると、NextCloud FMP Docker コンテナのコンソール ログから次のエラーが表示されます。

172.19.0.5 -  04/Mar/2023:22:36:01 +0000 "GET /index.php" 404

NGinX Docker コンテナのコンソール ログからのこのエラー:

172.69.67.108 - - [04/Mar/2023:22:36:01 +0000] "GET / HTTP/2.0" 404 36 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36" "xxx.my.ip.xxx"

Dockerサーバーホストとコンテナのセットアップ

  1. DockerホストサーバーのOSはUbuntu 22.04 LTSです

  2. NGinX Docker コンテナ、docker-compose.yml が最適であることはわかっていますが、今のところ、これが適切に動作するようになるまで、次のようにコンテナを実行しています。

    docker run -p 80:80 -p 443:443 --name nginx \
    --restart=unless-stopped \
    -v certbot:/etc/letsencrypt \
    -v nginx:/etc/nginx/conf.d \
    -v www:/usr/share/nginx/html \
    --network tools \
    -d nginx

    これは、ポートが公開されている Docker サーバー ホスト上の唯一のコンテナーであり、ボリューム マウントを使用して以下を共有します。

    • CertBot コンテナを使用した証明書
    • 各アプリのconfを設定するためのNGinX Confディレクトリ
    • NextCloud FPM Docker コンテナと共有する HTML www ルート ホーム
    • ネットワークツール

  3. NextCloud FPM Docker コンテナ。コンテナを次のように実行しています:

    docker run --name nextcloud-fpm \
    --restart=unless-stopped \
    -v www:/var/www/html \
    -e 'TRUSTED_PROXIES=nginx' \
    -e 'POSTGRES_HOST=database.server.com' \
    -e 'POSTGRES_USER=database_user' \
    -e 'POSTGRES_PASSWORD=database_user_password' \
    -e 'POSTGRES_DB=databse_name' \
    --network tools \
    -d nextcloud:fpm

    このコンテナは同じネットワークツール上で実行されるため、Dockerホストサーバーにアプリのポートを公開する必要がなく、プロキシリバースのIPではなくコンテナ名を使用してコンテナスタックとNGinX confファイルを作成するときに簡単になります。

    • NGinX Docker コンテナと共有する HTML www ルート ホーム
    • 信頼できるプロキシ（NGinXコンテナ）の環境変数
    • PostgreSQL データベースの環境変数
    • このコンテナはポート9000でFPMを実行します
    • ネットワークツール

  4. NGinX conf ファイルは 2 つあり、1 つは default.conf で、主に IP とポートでホスト サーバーに直接アクセスできないようにします (例: xxx.xxx.xxx.xxx:80 または xxx.xxx.xxx.xxx:443)。

    server {
    # Removes Web Server Info
    server_tokens off;
    # HTTP
    listen      80 default_server;
    listen [::]:80 default_server;
    listen      443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;
    ssl_reject_handshake on;
    # Identify Server without the name, hence just IP
    server_name _;
    # Return Empty Response
    return 444;
}

    最後にnextcloud.confは、GitHub NextCloud FPM 公式リポジトリ:

    upstream php-handler {
    server nextcloud-fpm:9000; # In here I set up the Stream with the NextCloud FPM Container name
}

server {
listen 80;
listen [::]:80;
server_name nextcloud.example.com;

return 301 https://$server_name$request_uri;
}

server {
listen 443 ssl;
listen [::]:443 ssl;
server_name nextcloud.example.com;

ssl_certificate /etc/letsencrypt/live/nextcloud.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/nextcloud.example.com/privkey.pem;

    # HSTS settings
    # WARNING: Only add the preload option once you read about
    # the consequences in https://hstspreload.org/. 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/vnd.ms-fontobject application/x-font-ttf application/>
    # 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 /usr/share/nginx/html/; # Since NGinX is the Web Server, I am pointing root to where the NextCloud Files are mounted inside the NGinX Container from the NextCloud FPM Container

    # 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;
    }
}

これまで試したこと

  1. 私の最初の直感は、この投稿の冒頭で共有したログを確認することでした。それに基づいて、両方のコンテナーにファイルが存在するかどうかを確認しました。これを 2 つの異なる方法で実行しました。

    同じ Docker ホスト サーバー上で実行されている Portainer のコンテナーがあり、プロキシ リバースとして正常な NGinX Docker コンテナーの背後にも実行されていますdocker exec container_name -it bash。コンソールを接続して、両方のコンテナー内のファイルを検索し、両方のコンテナーで次の操作を実行しました。

    NGinX コンテナマウントがオンになっていたことを思い出してください/usr/share/nginx/html

    root@61564cff4e67:/# ls -lha /usr/share/nginx/html
total 180K
drwxrwxrwx 15 www-data www-data 4.0K Mar  4 13:24 .
drwxr-xr-x  3 root     root     4.0K Feb  9 04:36 ..
-rw-r--r--  1 www-data www-data 3.2K Mar  4 13:24 .htaccess
-rw-r--r--  1 www-data www-data  101 Mar  4 13:24 .user.ini
drwxr-xr-x 47 www-data www-data 4.0K Mar  4 13:24 3rdparty
-rw-r--r--  1 www-data www-data  19K Mar  4 13:24 AUTHORS
-rw-r--r--  1 www-data www-data  34K Mar  4 13:24 COPYING
drwxr-xr-x 50 www-data www-data 4.0K Mar  4 13:24 apps
drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 config
-rw-r--r--  1 www-data www-data 4.0K Mar  4 13:24 console.php
drwxr-xr-x 23 www-data www-data 4.0K Mar  4 13:24 core
-rw-r--r--  1 www-data www-data 6.2K Mar  4 13:24 cron.php
drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 custom_apps
drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 data
drwxr-xr-x  2 www-data www-data  12K Mar  4 13:24 dist
-rw-r--r--  1 www-data www-data  156 Mar  4 13:24 index.html
-rw-r--r--  1 www-data www-data 3.4K Mar  4 13:24 index.php
drwxr-xr-x  6 www-data www-data 4.0K Mar  4 13:24 lib
-rwxr-xr-x  1 www-data www-data  283 Mar  4 13:24 occ
drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 ocm-provider
drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 ocs
drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 ocs-provider
-rw-r--r--  1 www-data www-data 3.1K Mar  4 13:24 public.php
-rw-r--r--  1 www-data www-data 5.5K Mar  4 13:24 remote.php
drwxr-xr-x  4 www-data www-data 4.0K Mar  4 13:24 resources
-rw-r--r--  1 www-data www-data   26 Mar  4 13:24 robots.txt
-rw-r--r--  1 www-data www-data 2.4K Mar  4 13:24 status.php
drwxr-xr-x  3 www-data www-data 4.0K Mar  4 13:24 themes
-rw-r--r--  1 www-data www-data  383 Mar  4 13:24 version.php

    NextCloud FPM コンテナマウントがオンになっていたことを思い出してください/var/www/html

    root@938c95d0e1ae:/var/www/html# ls -lha
total 180K
drwxrwxrwx 15 www-data www-data 4.0K Mar  4 13:24 .
drwxrwxr-x  1 www-data root     4.0K Feb 16 03:06 ..
-rw-r--r--  1 www-data www-data 3.2K Mar  4 13:24 .htaccess
-rw-r--r--  1 www-data www-data  101 Mar  4 13:24 .user.ini
drwxr-xr-x 47 www-data www-data 4.0K Mar  4 13:24 3rdparty
-rw-r--r--  1 www-data www-data  19K Mar  4 13:24 AUTHORS
-rw-r--r--  1 www-data www-data  34K Mar  4 13:24 COPYING 
drwxr-xr-x 50 www-data www-data 4.0K Mar  4 13:24 apps
drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 config
-rw-r--r--  1 www-data www-data 4.0K Mar  4 13:24 console.php
drwxr-xr-x 23 www-data www-data 4.0K Mar  4 13:24 core
-rw-r--r--  1 www-data www-data 6.2K Mar  4 13:24 cron.php
drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 custom_apps
drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 data
drwxr-xr-x  2 www-data www-data  12K Mar  4 13:24 dist
-rw-r--r--  1 www-data www-data  156 Mar  4 13:24 index.html
 -rw-r--r--  1 www-data www-data 3.4K Mar  4 13:24 index.php
drwxr-xr-x  6 www-data www-data 4.0K Mar  4 13:24 lib
-rwxr-xr-x  1 www-data www-data  283 Mar  4 13:24 occ
drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 ocm-provider
drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 ocs
drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 ocs-provider
-rw-r--r--  1 www-data www-data 3.1K Mar  4 13:24 public.php
-rw-r--r--  1 www-data www-data 5.5K Mar  4 13:24 remote.php
drwxr-xr-x  4 www-data www-data 4.0K Mar  4 13:24 resources
-rw-r--r--  1 www-data www-data   26 Mar  4 13:24 robots.txt
-rw-r--r--  1 www-data www-data 2.4K Mar  4 13:24 status.php
drwxr-xr-x  3 www-data www-data 4.0K Mar  4 13:24 themes
-rw-r--r--  1 www-data www-data  383 Mar  4 13:24 version.php

    Docker サーバー ホスト バインド マウント最後に、両方のコンテナのルートの場所を共有するだけでなく、コンテナを移動する必要がある場合に永続的なデータも保持したいため、Docker ホスト サーバー自体のファイルを確認します。

    ❯ ll
total 180K
drwxrwxrwx 15 www-data  www-data  4.0K Mar  4 13:24 .
drwxrwxr-x 10 Alejandro Alejandro 4.0K Mar  4 13:24 ..
drwxr-xr-x 47 www-data  www-data  4.0K Mar  4 13:24 3rdparty
drwxr-xr-x 50 www-data  www-data  4.0K Mar  4 13:24 apps
-rw-r--r--  1 www-data  www-data   19K Mar  4 13:24 AUTHORS
drwxr-xr-x  2 www-data  www-data  4.0K Mar  4 13:24 config
-rw-r--r--  1 www-data  www-data  4.0K Mar  4 13:24 console.php
-rw-r--r--  1 www-data  www-data   34K Mar  4 13:24 COPYING
drwxr-xr-x 23 www-data  www-data  4.0K Mar  4 13:24 core
-rw-r--r--  1 www-data  www-data  6.2K Mar  4 13:24 cron.php
drwxr-xr-x  2 www-data  www-data  4.0K Mar  4 13:24 custom_apps
drwxr-xr-x  2 www-data  www-data  4.0K Mar  4 13:24 data
drwxr-xr-x  2 www-data  www-data   12K Mar  4 13:24 dist
-rw-r--r--  1 www-data  www-data  3.2K Mar  4 13:24 .htaccess
-rw-r--r--  1 www-data  www-data   156 Mar  4 13:24 index.html
-rw-r--r--  1 www-data  www-data  3.4K Mar  4 13:24 index.php
drwxr-xr-x  6 www-data  www-data  4.0K Mar  4 13:24 lib
-rwxr-xr-x  1 www-data  www-data   283 Mar  4 13:24 occ
drwxr-xr-x  2 www-data  www-data  4.0K Mar  4 13:24 ocm-provider
drwxr-xr-x  2 www-data  www-data  4.0K Mar  4 13:24 ocs
drwxr-xr-x  2 www-data  www-data  4.0K Mar  4 13:24 ocs-provider
-rw-r--r--  1 www-data  www-data  3.1K Mar  4 13:24 public.php
-rw-r--r--  1 www-data  www-data  5.5K Mar  4 13:24 remote.php
drwxr-xr-x  4 www-data  www-data  4.0K Mar  4 13:24 resources
-rw-r--r--  1 www-data  www-data    26 Mar  4 13:24 robots.txt
-rw-r--r--  1 www-data  www-data  2.4K Mar  4 13:24 status.php
drwxr-xr-x  3 www-data  www-data  4.0K Mar  4 13:24 themes
-rw-r--r--  1 www-data  www-data   101 Mar  4 13:24 .user.ini
-rw-r--r--  1 www-data  www-data   383 Mar  4 13:24 version.php

root@myserver /mnt/Volume/data/www

    権限の面で動作しない理由は見当たらず、3 つのインスタンスすべてにファイルが存在することを確認しました。

  2. NextCloud FPM nextcloud.conf の NGinX conf ファイルを確認してください。よく検討した結果、ブラウザーのドメイン経由で NGniX Web サーバー コンテナーにアクセスしているため、ログに 404 Not Found エントリがあり、NextCloud コンテナー インスタンス自体からも 404 Not Found の応答が返されていることから、唯一間違っている可能性があるのは、conf ファイルのルート エントリに関連していることだと考えられます。

    NextCloud ログ:

    172.19.0.5 -  04/Mar/2023:22:36:01 +0000 "GET /index.php" 404

    NGinX ログ:

    172.69.67.108 - - [04/Mar/2023:22:36:01 +0000] "GET / HTTP/2.0" 404 36 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36" "xxx.my.ip.xxx"

    そこで、ルート ディレクティブを に変更する/var/www/htmlと、動作が少し変わり、404 Not Found エントリが引き続き表示されますが、これは NGinX Web サーバー コンテナーのログにのみ表示され、NextCloud コンテナーはサイレントなので、この変更では到達しません。

    NextCloud ログ(何も入力しない場合は空):

    NGinX ログ:

    2023/03/05 00:13:24 [error] 473#473: *4152 "/var/www/html/index.php" is not found (2: No such file or directory), client: 172.69.65.73, server: nextcloud.example.com, request: "GET / HTTP/2.0", host: "nextcloud.example.com"
172.69.65.73 - - [05/Mar/2023:00:13:24 +0000] "GET / HTTP/2.0" 404 174 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36" "xxx.my.ip.xxx"

    "nextcloud.example.com"Web サーバーの動作に何か違いがあり、ルート ディレクティブの変更後、以前はダッシュだけだった実際のドメインが、ログに引用符で囲まれて表示されることに気付きました"-"。

  3. 次に、default.conf NGinX conf ファイルを無効にするだけでした。これが唯一考えられる場所なので"-"、上記と同じ結果になり、すでに試したシナリオ 1 と 2 の両方で繰り返しましたが、これは"_"default.conf のサーバー ディレクティブでもあるため、当てずっぽうでした。

  4. conf で他の多くの設定を試しましたが、ほとんどがToo Many Redirections、Bad Certificate、または単なる502エラーになってしまいます。

何が問題で、どこで行き詰まっているのかの判断

目的のドメインを持つブラウザから両方のコンテナにアクセスし、SSL も正常に解決されているため、目的の結果に非常に近いようですが、サーバー名が NGinX conf ファイルによってキャプチャされていないようで、NextCloud に正しく渡されません。何を変更すればよいのか正確にはわかりません。

特定の問題と思われるものに絞り込んだと思うので、誰かが NGinX の設定ファイル nextcloud.conf を確認して、何が間違っているのかを指摘してくれるかもしれません。

こんなに長い投稿を読んでくださってありがとうございます。

答え1

私はそれを理解したので、これに関して答えのない質問や問題がいくつも見つかったことを考慮して、すでに同じ問題を抱えている人や将来この問題に遭遇する可能性のある人を助けるために詳細な情報を提供します。

問題は、NGinX conf ファイルの FastCGI パラメータの FPM ルートの場所でした。

つまり、私は正しい方向に進んでおり、問題はルート ディレクティブに関連していました。

いろいろ読んでいるうちに、偶然この投稿を見つけました。

php-fpm と Nginx Docker コンテナを正しくリンクするにはどうすればよいですか?

そして突然、2 つの異なるパスを読み取る 2 つの異なるサービスがあり、一方が他方のルート パスを存在しない場所にフィードしていることが明らかになりました。

2 つのコンテナー間で共有されるように www ボリュームをマウントしたことを覚えていますか?

  1. NGinXコンテナの場合www:/usr/share/nginx/html
  2. NextCloud FPMコンテナの場合www:/var/html/www

この背後にある考え方は、2 つのコンテナが NextCloud アプリのファイルシステムを共有するというものでした。

私が気付いていなかったのは、このデプロイメントでは、NGinX の目的は、FastCGI パラメータを使用して PHP 呼び出しを NextCloud FPM コンテナにルーティングしながら、CSS、HTML、JPG、JS などの静的ファイルを提供することだということです。

NGinX conf ファイルでルート ディレクティブが宣言されると、それが変数として設定されます$document_root。

root /usr/share/nginx/html;

したがって、ルートを NGinX コンテナのパスに設定すると、/usr/share/nginx/html問題なく静的ファイルを提供することができますが、PHP 呼び出しが行われると、NextCloud FPM コンテナの php-hander に渡されますが、その場所は 2 番目のコンテナ内に存在しないため、PHP ファイルを見つけることができません。

これを修正するために、FastCGI パラメータを含むブロックを検索し、変数を検索して$document_root見つけました。結果は次のようになりました。

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;
        }

という行がfastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;、ルートがすでに宣言されているスクリプト パスを形成していることに注意してください。処理時にnextcloud.example.com読み取りを試行しindex.php、結果として NextCloud FPM コンテナーへの呼び出しが行われます。

/usr/share/nginx/html/index.php

正しい呼び出しは次のようになります。

/var/www/html/index.php

そこで、 という名前の新しい変数を作成し$fpm_root、 に設定し/var/www/html/、 という行fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;を に変更しました。fastcgi_param SCRIPT_FILENAME $fpm_root$fastcgi_script_name;

これで、静的コンテンツの呼び出しを受けるたびに NGinX のコンテナ パスが解決され、PHP コンテンツの呼び出しを受けるたびに NextCloud FPM のコンテナ パスが解決されるようになります。

セクション全体の様子は以下のとおりです。

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;
            set $fpm_root /var/www/html/;

            try_files $fastcgi_script_name =404;

            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $fpm_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;
        }

次の行を追加すると、動作するようになり、すべての内部 NextCloud のヘルス チェックとセキュリティ チェックに合格します。

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

結論

そして、これがこの問題を探しているすべての人に役立つことを願っています。問題は、静的コンテンツと PHP コンテンツの両方を処理するサービスに 2 つの異なるパスがあり、そのうちの 1 つだけが NGinX conf ファイルで適切に設定されていたことです。

Docker 化された FPM デプロイメントには 2 つの異なる (またはそれ以上の) ルート ロケーションを設定できます。これにより、同じ FPM コンテナーを使用して静的コンテンツを 2 つ以上の異なるアプリにデプロイし、NextCloud、WordPress、PHPPGAdmin、Laravel などの PHP 呼び出しを処理できるようになります。

関連情報