Une page de connexion fonctionne, mais Nextcloud crée des liens en HTTP, journalise l’adresse du proxy ou tourne en boucle après l’authentification. En 2026, ces symptômes viennent souvent d’un reverse proxy Nextcloud mal déclaré, pas de l’application elle-même.
Le frontal HTTPS doit transmettre le bon nom d’hôte, le protocole et l’adresse d’origine. Nextcloud doit ensuite faire confiance au proxy, sans accepter les mêmes en-têtes depuis n’importe quel client. Ce guide explique les paramètres trusted_proxies, forwarded_for_headers et overwrite*, puis propose une recette de validation avant la production. Pour replacer ce composant dans l’ensemble de la plateforme, consultez le guide complet de Nextcloud.
Quel est le rôle d’un reverse proxy devant Nextcloud ?
Un proxy inverse reçoit les requêtes publiques avant le serveur Nextcloud. Il peut terminer la connexion TLS, sélectionner un nœud applicatif, appliquer une limite de débit ou publier plusieurs services derrière une même adresse IP. Le navigateur voit par exemple https://cloud.exemple.fr, tandis que le proxy contacte Nextcloud sur une adresse privée et parfois en HTTP.
Cette séparation crée deux visions de la même requête. Le frontal connaît la connexion publique. Le serveur d’application voit directement l’adresse du proxy, son protocole interne et le port du backend. Sans transmission correcte, Nextcloud peut croire que la visite est arrivée en HTTP sur une adresse interne. Il risque alors de générer une redirection, une URL WebDAV ou un lien de notification incohérent.
Trois familles de réglages doivent rester distinctes :
| Réglage | Question traitée | Erreur fréquente |
|---|---|---|
trusted_domains | Quels noms d’hôte peuvent servir à ouvrir l’instance ? | Y placer l’adresse du proxy au lieu du domaine public |
trusted_proxies | Quels intermédiaires sont autorisés à fournir l’adresse cliente ? | Faire confiance à tout un réseau sans nécessité |
overwrite* | Quelle URL publique Nextcloud doit-il reconstruire ? | Forcer des valeurs alors que la détection fonctionne déjà |
Le proxy n’est pas une protection autonome. Il faut aussi maintenir Nextcloud, PHP, le serveur web et les certificats. Le guide de sécurité Nextcloud détaille ces autres couches, notamment la double authentification, les mises à jour et les sauvegardes.
Comment déclarer trusted_proxies et les en-têtes transférés ?
trusted_proxies contient les adresses des proxys qui contactent directement Nextcloud. La documentation accepte les adresses IPv4, IPv6 et les plages CIDR. Inscrivez l’adresse réellement observée par le backend. Dans un réseau de conteneurs, elle peut différer de l’adresse configurée sur l’hôte, d’où l’intérêt de vérifier les journaux avant de remplir la liste.
Voici une structure minimale avec une adresse réservée aux exemples. Elle ne doit pas être copiée telle quelle en production :
<?php
$CONFIG = [
'trusted_proxies' => [
'192.0.2.10',
],
];
Le paramètre forwarded_for_headers indique quels en-têtes contiennent l’adresse d’origine. Nextcloud utilise déjà HTTP_X_FORWARDED_FOR par défaut. Ne redéfinissez pas ce tableau par habitude. Changez-le uniquement si votre frontal emploie un autre en-tête documenté et supprime les valeurs fournies directement par le client.
La chaîne de confiance est le point sensible. Si Nextcloud accepte un en-tête d’adresse depuis une source non maîtrisée, un visiteur peut falsifier l’adresse enregistrée. La protection contre les connexions répétées, les règles d’accès et l’analyse d’incident peuvent alors viser la mauvaise machine. À l’inverse, si le proxy n’est pas déclaré, tous les utilisateurs peuvent apparaître avec la même adresse, celle du frontal.
Ne faites confiance qu’au dernier saut maîtrisé
Le serveur Nextcloud doit accepter les en-têtes transférés seulement depuis les adresses de proxy prévues. Évitez les plages plus larges que l’architecture réelle et vérifiez le comportement après chaque changement de réseau ou de conteneur.
Le proxy doit lui aussi transmettre des valeurs cohérentes. Le nom d’hôte public correspond généralement à l’en-tête Host. Le protocole d’origine est souvent signalé par X-Forwarded-Proto. L’adresse cliente circule habituellement dans X-Forwarded-For. Les noms exacts et leur traitement dépendent du frontal utilisé, de ses modules et des intermédiaires placés avant lui.
Pour confirmer le résultat, consultez une requête récente dans nextcloud.log et contrôlez le champ remoteAddr. Le guide Nextcloud Activity et audit explique pourquoi cette adresse reste un indice technique à recouper avec les journaux du proxy et du serveur web.
Quand utiliser overwritehost, overwriteprotocol et overwritewebroot ?
Nextcloud essaie normalement de détecter le nom d’hôte, le protocole et le chemin public à partir de la requête. Les paramètres overwrite* servent quand cette détection échoue derrière un frontal. La documentation précise qu’ils ne sont pas nécessaires dans la plupart des déploiements. Commencez donc par corriger les en-têtes transmis avant de forcer l’URL dans config.php.
overwriteprotocol est utile lorsque le proxy termine HTTPS puis contacte le backend en HTTP et que Nextcloud continue à produire des URL non chiffrées. La valeur attendue est http ou https. overwritehost impose le nom d’hôte, avec un port si nécessaire. overwritewebroot ajoute le chemin public d’une installation exposée dans un sous-répertoire, par exemple /nextcloud.
<?php
$CONFIG = [
'trusted_proxies' => ['192.0.2.10'],
'overwriteprotocol' => 'https',
'overwritehost' => 'cloud.exemple.fr',
'overwrite.cli.url' => 'https://cloud.exemple.fr',
];
Cet exemple illustre les clés, pas une configuration universelle. N’ajoutez overwritehost que si le domaine doit réellement être imposé. Avec plusieurs noms d’accès, un hôte forcé peut renvoyer tous les utilisateurs vers le même domaine. overwritecondaddr permet de limiter les paramètres d’écrasement aux requêtes provenant d’une adresse de proxy correspondant à une expression régulière.
overwrite.cli.url répond à un autre contexte. Les tâches lancées en ligne de commande ou par cron ne reçoivent pas de requête web publique dont déduire l’adresse. Ce paramètre fournit alors l’URL de base. Il doit inclure le chemin complet si Nextcloud est publié dans un sous-répertoire.
Après modification, contrôlez au minimum la page de connexion, un partage public, un e-mail généré par Nextcloud et l’URL WebDAV affichée dans l’application Fichiers. Un seul test dans le navigateur ne suffit pas, car les tâches de fond et les clients peuvent construire leurs liens autrement.
Quelles routes le proxy doit-il laisser fonctionner ?
Le frontal doit transporter les méthodes et chemins utilisés par l’interface, WebDAV, les applications et les points de découverte. Les redirections /.well-known/carddav et /.well-known/caldav doivent atteindre /remote.php/dav/. Selon les applications actives, webfinger et nodeinfo peuvent aussi demander une règle de découverte. Nextcloud recommande d’ajouter ces redirections dans le proxy lorsque celui-ci se trouve devant le serveur web de l’instance.
Ne réduisez pas le trafic à GET et POST. WebDAV utilise notamment des méthodes comme PROPFIND, PUT, MOVE et DELETE. Une règle de sécurité trop restrictive peut laisser fonctionner la page web tout en cassant les clients. Le guide Nextcloud WebDAV décrit les URL, les mots de passe d’application et les erreurs de chemin ou d’authentification.
Les services avec connexion persistante exigent leur propre contrôle. Notify Push, Talk ou une suite bureautique peuvent employer WebSocket ou des chemins dédiés. Une réussite sur /status.php ne prouve donc pas que ces services traversent le frontal. Inventoriez les applications réellement utilisées, puis testez chaque parcours au lieu de reprendre une configuration prévue pour une autre installation.
Nextcloud All-in-One possède une procédure spécifique pour les proxys externes. Sa documentation demande un nom d’hôte dédié et n’accepte pas une publication dans un sous-répertoire. Elle fournit aussi des exemples distincts pour Apache, Caddy, Nginx, Nginx Proxy Manager et Traefik. Utilisez le modèle officiel correspondant au produit installé plutôt qu’un bloc générique trouvé pour une archive classique.
Dans une architecture avec plusieurs nœuds, le proxy devient aussi un répartiteur de charge. Les paramètres d’URL restent nécessaires, mais ils ne règlent ni les sessions partagées, ni Redis, ni la base, ni le stockage. Le guide Nextcloud haute disponibilité couvre ces dépendances et les tests de bascule.
Comment tester et dépanner la configuration ?
Préparez d’abord un retour arrière. Sauvegardez config.php, validez la syntaxe du proxy et gardez une session d’administration ouverte si la procédure de changement le permet. Modifiez une seule couche à la fois. Sinon, une redirection corrigée peut masquer une adresse cliente toujours fausse.
Cette recette couvre les parcours principaux :
- ouvrir le domaine public en navigation privée et vérifier qu’il reste en HTTPS ;
- contrôler que
/status.phprépond sur le domaine attendu ; - ouvrir
/.well-known/caldavet/.well-known/carddav, puis vérifier leur redirection ; - créer un partage de test et examiner le domaine ainsi que le protocole de son URL ;
- copier l’URL WebDAV depuis Nextcloud et tester une lecture puis une écriture ;
- déclencher un e-mail ou une notification contenant un lien ;
- comparer l’adresse cliente dans les journaux du proxy et dans
nextcloud.log; - consulter les avertissements de la vue d’ensemble d’administration ;
- répéter les tests depuis un second réseau, par exemple une connexion mobile.
Vous pouvez aussi lire la configuration effective avec occ, en adaptant le chemin et l’utilisateur du serveur web :
sudo -u www-data php occ config:system:get trusted_proxies
sudo -u www-data php occ config:system:get overwriteprotocol
sudo -u www-data php occ config:system:get overwritehost
sudo -u www-data php occ config:system:get overwrite.cli.url
Une boucle de redirection indique souvent un désaccord sur le protocole ou l’hôte. Des liens en HTTP orientent vers la transmission du protocole et overwriteprotocol. Si tous les comptes partagent la même adresse dans les journaux, examinez trusted_proxies et la chaîne X-Forwarded-For. Une erreur 413 concerne plutôt la taille acceptée par une couche, tandis qu’un 504 conduit à étudier les délais du frontal et du backend.
Validez la sécurité après la connectivité
Une instance accessible peut encore journaliser une adresse falsifiable. Après les tests fonctionnels, lancez le scanner officiel Nextcloud, examinez les avertissements d’administration et confirmez que les en-têtes ne sont acceptés que depuis le proxy.
Conclusion
Un reverse proxy Nextcloud fiable repose sur une chaîne cohérente : domaine public autorisé, proxy précisément déclaré, en-têtes nettoyés, protocole HTTPS reconnu et routes applicatives testées. Évitez de forcer tous les paramètres overwrite* par défaut. Corrigez d’abord la transmission, puis ajoutez seulement les valeurs nécessaires. La recette finale doit vérifier le navigateur, WebDAV, les liens générés, les tâches en ligne de commande et l’adresse cliente observée.