`Your web server is not properly set up to resolve .well-known URLs, failed on: /.well-known/webfinger`

[monochromec]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

.well-known checks on Admin page

Steps to reproduce

1. Ran extcloud/settings/admin/overview
2. Got .well-known URLs
   Your web server is not properly set up to resolve .well-known URLs, failed on: /.well-known/webfinger
   error message:
   {"reqId":"uBjvhhmoOD3PxuwYBvKQ","level":0,"time":"2026-02-20T13:29:13+01:00","remoteAddr":"127.0.0.1","user":"--","app":"serverDI","method":"GET","url":"/nextcloud/index.php/.well-known/webfinger","message":"The requested alias \"OCP\\IServerContainer\" is deprecated. Please request \"Psr\\Container\\ContainerInterface\" directly. This alias will be removed in a future Nextcloud version.","userAgent":"Nextcloud Server Crawler","version":"32.0.0.13","data":{"app":"serverDI"}}

Expected behavior

.well-known check passing w/o error

nginx.conf (excerpt):

 location ^~ /.well-known {                                                                                  

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

                 location /.well-known/acme-challenge    { root /opt; try_files $uri $uri/ =404; }
                 location /.well-known/pki-validation    { try_files $uri $uri/ =404; }
                 return 301 /nextcloud/index.php$request_uri;
		...
}

Nextcloud Server version

32

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.4

Web server

Nginx

Database engine version

SQlite

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "<hostname>",
            "localhost"
        ],
        "overwrite.cli.url": "https:\/\/<hostname>\/nextcloud",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "sqlite3",
        "version": "32.0.0.13",
        "installed": true,
        "memcache.local": "\\OC\\Memcache\\APCu",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "filelocking.enabled": true,
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0,
            "timeout": 1.5,
            "dbindex": 0
        },
        "loglevel": 2,
        "log_type": "file",
        "cron_log": true,
        "log_rotate_size": 0,
        "defaultapp": "files",
        "default_phone_region": "DE",
        "remember_login_cookie_lifetime": 1296000,
        "session_lifetime": 86400,
        "updatechecker": false,
        "logtimezone": "Europe\/Berlin",
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "enable_previews": true,
        "preview_max_x": 100,
        "preview_max_y": 100,
        "maintenance_window_start": 1,
        "maintenance": false,
        "theme": "",
        "integrity.check.disabled": true,
        "data-fingerprint": "817381a21dafe9dfaf6f3464f7de5a63"
    }
}

List of activated Apps

Default apps which came with installation.

Nextcloud Signing status

Nextcloud Logs

Additional info

No response

[joshtrichards]

What is the output of curl -I http://https://<hostname>/.well-known/webfinger from the command-line of the host running your Nextcloud instance?

The deprecation message is logged only; it's unlikely to be related.

It would also be helpful if you filled out the other aspects of the Issue template; especially since there are various apps that intercept the webfinger handler (e.g. social), but you didn't fill out the full Issue template.

[monochromec]

HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Sat, 21 Feb 2026 15:39:59 GMT
Content-Type: text/html
Content-Length: 162
Location: https://<hostname>/nextcloud/index.php/.well-known/webfinger
Connection: keep-alive
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

HTTP/1.1 404 Not Found
Server: nginx
Date: Sat, 21 Feb 2026 15:39:59 GMT
Content-Type: text/html
Content-Length: 389
Connection: keep-alive
ETag: "6996ccaf-185"
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

nginx access log:

<IP> - - [21/Feb/2026:16:39:59 +0100] "GET /.well-known/webfinger HTTP/1.1" 301 162 "-" "curl/8.7.1" "-"
<IP>- - [21/Feb/2026:16:39:59 +0100] "GET /nextcloud/index.php/.well-known/webfinger HTTP/1.1" 404 389 "-" "curl/8.7.1" "-"

nginx error log:

2026/02/21 16:39:59 [notice] 2415113#2415113: *4178 "^/nextcloud/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|ocs-provider\/.+|.+\/richdocumentscode\/proxy)" does not match "/nextcloud/index.php/.well-known/webfinger", client: <IP>, server: <hostname>, request: "GET /nextcloud/index.php/.well-known/webfinger HTTP/1.1", host: "<hostname>"
```

[lineumaciel]

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

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

    location ^~ /.well-known {
        return 301 /index.php$request_uri;
    }

Try this.

[monochromec]

That only works if NC is residing in a top-level directory (ie. root) on the webserver.

Which is not the case.

[joshtrichards]

Did this setup work previously?

The curl output lacks Nextcloud headers, suggesting you're not even hitting Nextcloud's front-end controller. That's the reason why the test is failing (the setup check looks for the X-NEXTCLOUD-WELL-KNOWN header that gets added by the handlers).

Couple things:

• Your config says you have reverse proxy. The well-known handle redirects should be on your reverse proxy, not on your web server (see https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html#nginx)
• You may need to set overwritewebroot to /nextcloud

Given you're reporting this with an outdated version of v32 (32.0.0; we're up to 32.0.6), and we haven't seen a bunch of reports about this problem (and there are many users using subfolder deployments), I suspect something else is going on here.

I suggest you troubleshoot further via the community help forum: https://help.nextcloud.com

[monochromec]

A little of digging did indeed reveal the RC of the issue:
Setting the NC loglevel to 0 did indeed reveal that the .well-known/webfinger invocation as part of apps/settings/lib/SetupChecks/WellKnownUrls.php (this is the check invoked by the admin overview page) made it to core/Controller/WellKnownController.php. This file also did inject X-NEXTCLOUD-WELL-KNOWN into the header (which apps/settings/lib/SetupChecks/WellKnownUrls.php does check if presented with a 404) according to plan, but nginx's configuration in the shape of fastcgi_intercept_errors on; (if you invoke PHP code via fpm as my config does) removes nicely :-) so that the admin page check assumes foul play as the error message indicates.

Remove this statement (or set this to off in your nginx config) and the check works as expected.

Closing this due to a solution in place.