Oui, les 2 sont pour P2P.
Je pense que le --listen-addr sert à déclarer au serveur d’utiliser un port (interne) particulié pour le P2P (permet également de préciser si en WebSocket ou pas).
Lié à cette entrée là, tu dois potentiellement mapper le port (interne) précisé vers le Host si tu veux l’exposer publiquement (dans la section ports:).
Et le --public-addr est je pense uniquement pour le partage des endpoints (et il faut bien y renseigner le port et/ou dns accessible depuis l’extérieur).
Autre chose, si tu utilises les arguments --listen-addr et --public-addr dans les command:; je pense qu’il faut faire attention à retirer les variables d’environment: : DUNITER_LISTEN_ADDR et DUNITER_PUBLIC_ADDR !
Pour ma part, je n’ai pas eu de soucis ou les ports P2P sont aléatories; j’ai même fais un test en ouvrant 2 ports P2P en même temps pour avoir un en TCP brut et un en WebSocket et j’ai fait les tests de connectivités sur les 2 (même si au final, il ne vaut mieux garder qu’une seule déclaration P2P par serveur 
)
@Pini tu peux donner ton noeud pour lequel tu as des soucis ?
=> son DNS, le port que tu expose, et le node “identity” pour recomposer l’ “url” p2p
Exemple pour récupérer le node identity dans les logs de démarrage:
docker compose logs | grep "identity"
duniter-gtest-mirror-bn | 2026-03-21 17:40:42 Local node identity is: 12D3KooWD1mp5M1CsZnVuPWQBHs5PhGZfhSEtm6gh6UvypcVrpjh