[Bug]: `trusted_proxies` ignoring CIDRs larger than `/13`

[jordanbancino]

⚠️ 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

I do not recall exactly when this behavior started but it did not used to always be this way, it seems that something changed recently.

I run Nextcloud with Docker compose. My Nextcloud installation predates the Nextcloud AiO Docker images, so I have been building Nextcloud images from a base Alpine image. I have an ingress container that handles TLS and is network-facing, and it forwards all requests to my Nextcloud container. Since I let Docker handle all of the networking, I do not know what IP address it will assign to the ingress container. There is inherently some nondeterministic behavior when doing docker compose up -d across kernel versions and even boots of the same kernel.

All this is to say that I have intentionally configured trusted_proxies to be set to 172.16.0.0/12, the entire Docker network block, because at any given time I do not know where the ingress container is, and in fact there may be multiples spread out across that entire space. I also trust that entire subnet because I carefully control what containers are on it, so I do not see this as a security risk.

Recently, however, Nextcloud no longer seems to trust this network block. It simply reports that the proxy server's IP address is being throttled, as shown here:

That IP address is clearly within the trusted proxy range, so Nextcloud should be picking up the actual client IP instead. Indeed, I know my proxy server and Apache configuration are all correct here because when I set the trusted_proxies value to that IP address specifically, Nextcloud responds correctly with my actual client IP address and does not throttle it.

I can also set smaller CIDR ranges, such as 172.21.0.0/16, 172.20.0.0/15, 172.20.0.0/14, and 172.20.0.0/13, and these all work correctly. But as soon as I go up to 172.16.0.0/12, Nextcloud stops handling it correctly, and I'm not sure why, particularly given that this used to be a valid configuration.

It's possible that I'm doing something wrong. I know that ideally, I should know the exact IP of my ingress containers and eventually it is my goal to pin it, but I have not gotten around to it yet.

Steps to reproduce

1. Set up Nextcloud with Apache, probably in Docker.
2. Put a trusted reverse proxy in front of it, probably also in Docker.
3. Trust the entire /12 that the reverse proxy resides in via trusted_proxies.
4. Observe that Nextcloud sees the client IP address as the proxy server, not as the real client IP address as reported in X-Forwarded-For.
5. Trust a smaller block, such as /13, /14, /15, /16, or even just the exact proxy server IP address (/32), and observe that Nextcloud does honor X-Forwarded-For.

Expected behavior

Nextcloud's trusted_proxies configuration directive should accept 172.16.0.0/12 as a valid CIDR and trust all reverse proxies inside of that block. My trusted_proxies looks like this in config.php:

  'trusted_proxies' => 
  array (
    0 => '172.16.0.0/12',
  ),

However it does not seem to trust my proxy server at 172.21.0.7.

Nextcloud Server version

33

Operating system

Other

PHP engine version

PHP 8.5

Web server

Apache (supported)

Database engine version

PostgreSQL

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

Updated from a MINOR version (ex. 32.0.1 to 32.0.2)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

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

Configuration report

# doas -u apache php85 occ config:list system
{
    "system": {
        "integrity.check.disabled": false,
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "***REDACTED***"
        ],
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "forwarded_for_headers": [
            "HTTP_X_FORWARDED_FOR"
        ],
        "overwritehost": "***REDACTED***",
        "overwriteprotocol": "https",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "pgsql",
        "version": "33.0.3.2",
        "overwrite.cli.url": "http:\/\/localhost",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.local": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "mail_smtpmode": "smtp",
        "mail_sendmailmode": "pipe",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "default_phone_region": "US",
        "has_internet_connection": true,
        "maintenance": false,
        "maintenance_window_start": 6,
        "loglevel": 2,
        "log.condition": {
            "apps": [
                "admin_audit"
            ]
        },
        "mail_smtpport": "587",
        "theme": "",
        "app_install_overwrite": {
            "0": "tasks",
            "2": "passwords"
        },
        "defaultapp": "",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpstreamoptions": {
            "ssl": {
                "allow_self_signed": true,
                "verify_peer": false,
                "verify_peer_name": false
            }
        },
        "apps_paths": [
            {
                "path": "\/var\/www\/htdocs\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/htdocs\/apps-volume",
                "url": "\/apps-volume",
                "writable": true
            }
        ],
        "mail_smtpauth": true,
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "twofactor_enforced": "true",
        "twofactor_enforced_groups": [],
        "twofactor_enforced_excluded_groups": [],
        "enable_lazy_objects": false
    }
}

List of activated Apps

# doas -u apache php85 occ app:list
Enabled:
  - admin_audit: 1.23.0
  - appointments: 2.7.2
  - bookmarks: 16.1.4
  - bruteforcesettings: 6.0.0
  - calendar: 6.2.4
  - circles: 33.0.0
  - cloud_federation_api: 1.17.0
  - contacts: 8.4.5
  - contactsinteraction: 1.14.1
  - dav: 1.36.0
  - federatedfilesharing: 1.23.0
  - files: 2.5.0
  - files_antivirus: 6.2.0
  - files_downloadlimit: 5.1.0
  - files_external: 1.25.1
  - files_pdfviewer: 6.0.0
  - files_sharing: 1.25.2
  - files_trashbin: 1.23.0
  - files_versions: 1.26.0
  - flow_notifications: 4.0.0
  - forms: 5.2.7
  - groupfolders: 21.0.7
  - impersonate: 4.0.0
  - logreader: 6.0.0
  - lookup_server_connector: 1.21.0
  - notes: 5.0.0
  - notifications: 6.0.0
  - notify_push: 1.3.2
  - oauth2: 1.21.0
  - password_policy: 5.0.0
  - passwords: 2026.5.20
  - privacy: 5.0.0
  - profile: 1.2.0
  - provisioning_api: 1.23.0
  - related_resources: 4.0.0
  - richdocuments: 10.1.3
  - serverinfo: 5.0.0
  - settings: 1.16.0
  - sharebymail: 1.23.0
  - suspicious_login: 11.0.0
  - tables: 2.1.1
  - tasks: 0.17.1
  - text: 7.0.1
  - theming: 2.8.0
  - twofactor_backupcodes: 1.22.0
  - twofactor_nextcloud_notification: 7.0.0
  - twofactor_totp: 15.0.0
  - updatenotification: 1.23.0
  - viewer: 6.0.0
  - workflowengine: 2.15.0
Disabled:
  - activity: 6.0.0 (installed 6.0.0-dev.0)
  - announcementcenter: 7.3.0 (installed 7.3.0)
  - app_api: 33.0.0 (installed 32.0.0)
  - comments: 1.23.0 (installed 1.23.0)
  - dashboard: 7.13.0 (installed 7.7.0)
  - deck: 1.17.1 (installed 1.17.1)
  - encryption: 2.21.0
  - federation: 1.23.0 (installed 1.19.0)
  - files_reminders: 1.6.0 (installed 1.2.0)
  - firstrunwizard: 6.0.0 (installed 6.0.0-dev.0)
  - mail: 5.7.14 (installed 5.7.14)
  - nextcloud_announcements: 5.0.0 (installed 2.0.0)
  - photos: 6.0.0 (installed 6.0.0-dev.0)
  - recommendations: 6.0.0 (installed 1.6.0)
  - support: 5.0.0 (installed 1.10.0)
  - survey_client: 5.0.0 (installed 1.13.0)
  - systemtags: 1.23.0 (installed 1.19.0)
  - testing: 1.23.0
  - user_ldap: 1.24.0
  - user_status: 1.13.0 (installed 1.13.0)
  - weather_status: 1.13.0 (installed 1.5.0)
  - webhook_listeners: 1.5.0 (installed 1.1.0-dev)

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

Additional info

Operating System: Alpine Linux v3.23.4 in Docker.

The reverse proxy is Caddy, running in a different container.

[joshtrichards]

That's definitely odd. I don't see anything that seems like it should cause this behavior. And most of the relevant code has been in place for >=2 years (though there are changes in underlying dependencies).

What shows under your Admin settings->Overview (setup checks) when this occurs?

Any idea when - more precisely - it may have started behaving like this for you?

[algojogacor]

I found a related issue in the ForwardedForHeaders setup check — it was using in_array() for strict comparison which doesn't handle CIDR ranges. This means the setup check was never showing the "resolved" success message for CIDR-configured proxies.

Submitted PR #60315 that replaces the exact-match check with a comparison between raw REMOTE_ADDR and the resolved address from getRemoteAddress() (which already uses IpUtils::checkIp() internally).

However, I wasn't able to reproduce the specific /12 vs /13 discrepancy you described — the CIDR matching logic in Symfony's checkIp4() appears mathematically correct for both cases on 64-bit PHP. The IpUtils uses sprintf('%032b', ip2long(...)) + substr_compare() which should handle all subnet sizes identically. This might be an environment-specific issue (PHP 8.5 on Alpine/musl, or a specific config interaction).

Could you check if the error log contains any "Nextcloud trustedProxies has malformed entries" messages? Also, does the Admin → Overview setup check now show the resolved IP after this fix?