PiwiLAbruti

Et plus précisément : Est-ce que le paquet SMB Service est installé ? https://www.synology.com/fr-fr/dsm/packages/SMBService

Non, ça n'allait pas jusque là heureusement. L'UPS ne s'affichait plus dans Panneau de configuration > rubrique Matériel et alimentation > onglet UPS. Pour certains, débrancher l'USB et le rebrancher permettait à DSM d'afficher à nouveau l'UPS. Pour d'autres ce n'était pas suffisant, il fallait alors créer un tâche planifiée exécutée au démarrage avec la commande suivante : cd /usr/lib/systemd/system/syno-bootup-done.target.wants && ln -s ../ups-usb.service ./

Dans un premier temps, suis la documentation officielle. Tu verras le reste après.

Et il est où le port 443 dans tout ça ?

As-tu appliqué ce qui est indiqué dans la documentation ? https://docs.hedgedoc.org/guides/reverse-proxy/ Je te conseille de ne pas chiffrer les communications entre le proxy inverse et HedgeDoc.

C'est surprenant, c'est toi que les a ajoutés ? Par défaut, il ne devrait rien y avoir dans les en-têtes personnalisées (On parle bien des en-têtes dans DSM > Panneau de configuration > rubrique Portail de connexion > onglet Avancé > bouton [Proxy inversé] > Modifier un profil > onglet En-têtes personnalisés). As-tu ajouté les en-têtes WebSocket comme indiqué précédemment ?

Au passage, aucun port n'est ouvert : > nmap -Pn -sS -p 21-23,80,443,1234,1235,5000,5001 domain.tld Starting Nmap 7.80 ( https://nmap.org ) at 2025-11-19 10:40 Paris, Madrid Nmap scan report for domain.tld (0.0.0.0) Host is up. PORT STATE SERVICE 21/tcp filtered ftp 22/tcp filtered ssh 23/tcp filtered telnet 80/tcp filtered http 443/tcp filtered https 1234/tcp filtered hotline 1235/tcp filtered mosaicsyssvc1 5000/tcp filtered upnp 5001/tcp filtered commplex-link

Modifie le titre de ce sujet en le préfixant par [Résolu] …

Regarde dans les paramètres de HedgeDoc s'il ne faut pas y déclarer le nom d'hôte utilisé (ça ne devrait pas être nécessaire, mais certaines applications y sont sensibles). Vérifie que les WebSocket sont créés dans le profil du proxy inversé dans l'onglet En-tête personnalisé > bouton [Créer] > WebSocket. Il est plus que probable que HedgeDoc en ait besoin. Regarde aussi la séquence des URL appelées dans l'onglet Réseau des Outils de développement du navigateur ( [Ctrl]+[Shift]+[i] ), avec et sans proxy inverse. Une redirection incorrecte est peut-être à l'origine du problème.

Selon le protocole, le débit peut être réduit. Ce qui est souvent le cas avec des téléchargements torrent.

C'est l'Apple TV (ou n'importe quel autre lecteur multimédia) qui décodera le contenu 4K, le NAS ne fait qu'envoyer les données demandées par l'Apple TV. Il n'y a donc besoin d'aucune puissance particulière venant du NAS pour cet usage. Quel logiciel ?

Je ne connais pas d'outils pour la comparaison. Mais la différence pourrait se situer au niveau de la corbeille (trash) contenant les messages supprimés, par exemple. Il est possible que ce dossier ne soit pas utilisé lors de l'importation.

Vu l'importance du problème, je te conseille d'ouvrir un ticket auprès de l'assistance Synology (si ce n'est pas déjà fait). Est-ce que les NAS sont clients d'un Active Directory Microsoft ? Ou est-ce que l'un d'entre eux est utilisé comme serveur Active Directory avec le paquet ActiveDirectoryServer ? (paquet n'ayant reçu aucune mise à jour depuis 2018 au passage)

Non, ça n'a aucun rapport avec le port. C'est le NAS qui ajoute cette en-tête HTTP avant d'envoyer une requête à la Freebox. Il n'y a aucun intérêt à chiffrer les échanges entre le NAS et la Freebox, mais les deux fonctionnent (tcp/80 ou tcp/443). Je n'ai pas cherché à comprendre pourquoi la Freebox a un comportement différent en HTTP et en HTTPS, et ça ne m'intéresse pas. Orange faisait la même chose avec les Livebox v4 où il fallait l'en-tête Host: 192.168.1.1 pour y accéder, je ne sais pas si c'est le cas sur les modèles plus récents.

Est-ce que le champ Nom d'hôte ou IP statique est renseigné dans Panneau de configuration > rubrique Accès externe > onglet Avancé ?

Les protocoles de broadcast utilisés pour la découverte des équipements du réseau ne peuvent fonctionner que sur le même segment (donc ça ne fonctionne pas si les équipements sont sur des réseaux différents). Le mieux est de mapper un lecteur réseau sur le laptop.

L'en-tête personnalisé sert uniquement à tromper la Freebox en lui faisant croire que le nom d'hôte mafreebox.freebox.fr a été utilisé pour l'atteindre. C'est pour contourner l'erreur que tu avais indiquée : Ça n'a rien à voir avec le port 80. Si le NAS n'est pas accessible en IPv6, ça ne peut pas fonctionner. Le pare-feu IPv6 des Freebox (hors Freebox Pro) est un honte : c'est un gros interrupteur qui bloque ou autorise tout le trafic IPv6. Il n'y aucun moyen de filtrer le trafic sans rajouter un pare-feu digne de ce nom derrière la Freebox.

L'USW-Ultra peut très bien être alimenté en PoE+, ça fait simplement baisser le budget PoE disponible de 42W à 16W (de quoi brancher un U7-Lite). C'est indiqué sur la fiche du produit : https://techspecs.ui.com/unifi/switching/usw-ultra?subcategory=switching-utility Pour le 10GbE, il faut du 6a minimum (on peut même prendre moins sur de courtes distances). Les catégories supérieures supportent des fréquences plus élevées qui n'apportent rien de plus (à part payer plus pour le même résultat), il vaut mieux privilégier un blindage adapté à l'installation (ce qui comprend le câble ET les noyaux, surtout pour la qualité de l'alimentation PoE). Les câbles Grade 3 ou 3S disposent de deux brins (7 et 8) supportant une fréquence supérieure pour y passer un signal TNT (900MHz) ou satellite (2,2GHz). Autant dire que c'est obsolète aujourd'hui, surtout que c'est plus cher au mètre que du 6a mono S/FTP. Je ne sais pas pourquoi les électriciens persistent à en installer systématiquement.

Je ne comprends pas ta question (Quelle solution ? Quel port 80 ?).

Pour la Freebox, il faut ajouter l'en-tête Host: mafreebox.freebox.fr dans l'onglet En-tête personnalisé.

Tu n'as que le port tcp/443 à ouvrir à destination du NAS sur la Freebox. Ensuite, tout se fait dans le proxy inversé. Par exemple : dsm.domain.synology.me > localhost:5000 freebox.domain.synology.me > 192.168.1.254:80 Si les restrictions d'accès du pare-feu ne sont pas suffisantes, je te conseille vivement de configurer des profils de contrôle d'accès dans le proxy inversé.

Si le port est bien ouvert sur la Freebox, ça ne vient pas de la Freebox. Je pencherais plutôt pour un blocage du port sortant depuis la connexion en Allemagne. Je ne connais aucune entreprise sérieuse qui laisse du trafic utilisateur sortir sur d'autres ports que les suivants (hors besoins exotiques) : HTTP (tcp/80) HTTPS/DoH (tcp/443) QUIC/DoQ (udp/443) D'où l'intérêt d'utiliser systématiquement le proxy inversé pour toutes les interfaces web (DSM inclus).

Tu n'as pas à t'excuser, et je moque totalement d'avoir raison. C'est juste que quand on demande quelque chose, c'est bien de montrer qu'on a cherché un minimum. Ça incite beaucoup plus d'autres à t'aider. Au passage, je n'ai pas trouvé de documentation exhaustive sur Turbobit pour faciliter la mise à jour.

Le mieux est d'utiliser tcpdump : tcpdump -nq 'port (443 or 1234 or 5001)'Ça affiche le trafic en amont du pare-feu du NAS. Donc ça permet de savoir si le trafic parvient bien jusqu'au NAS, peu importe qu'il soit bloqué ou non par le pare-feu.

Tu aurais dû le préciser. Car même si ce fichier .host a 10 ans, il peut toujours servir de base pour être mis à jour 🤷‍♂️