Traccar supporte ~266 protocoles GPS distincts. Chacun est auto-assigné à un port unique au démarrage, dans un ordre non documenté côté UI. Quand tu déploies Traccar derrière un firewall ou en conteneur Docker, tu n’exposes qu’une poignée de ports — il faut alors savoir précisément lequel correspond au protocole de ton tracker.
Pour les protocoles très courants (gt06=5023, osmand=5055) c’est connu. Pour les autres, devinette ou reverse engineering.
Symptôme
J’ai un tracker qui parle JT808 (identifié par sniff hex, cf [[71-identifier-protocole-tracker-gps-par-sniff-hex]]). Mon docker-compose.yml n’expose que 5023 / 5013 / 5055 / 5174 vers Internet (parce qu’on ne va pas mapper 266 ports). Je ne sais pas quel port Traccar a auto-attribué à JT808.
Le tracker, configuré pour parler à n’importe lequel des 4 ports exposés, est forcément à côté.
Cause
Traccar charge ses protocoles via ServiceLoader Java au démarrage. L’ordre d’instanciation détermine l’ordre d’auto-assignment des ports à partir de 5001+N. Cet ordre dépend de la version du JAR, change selon les releases, et n’est pas exposé via une commande, une API ou un fichier de config par défaut.
Il existe historiquement un conf/default.xml shipped avec Traccar 5.x qui listait les défauts, mais il a été retiré en v6 au profit d’un mapping en dur dans le code Java. Plus de fichier à lire.
Solution — forcer le port avec une entrée dans traccar.xml
<entry key='jt808.port'>5174</entry>Cette ligne dans conf/traccar.xml force le protocole jt808 à écouter sur 5174 (port que tu as déjà exposé), peu importe son port par défaut.
Format général : <entry key='<nom-protocole>.port'>N</entry>. Le nom du protocole = lowercase(NomProtocolClass) sans le suffixe Protocol. Exemples :
Jt808Protocol.class→jt808.portMicodusProtocol.class→micodus.portGt06Protocol.class→gt06.portHuabaoProtocol.class→huabao.port
Conflit possible : si un autre protocole utilise déjà ce port par défaut, désactive-le explicitement :
<entry key='micodus.enable'>false</entry>Vérification : docker exec traccar netstat -tnlp | grep :5174 doit montrer Java en LISTEN, et docker logs traccar au démarrage ne doit pas montrer d’erreur de bind.
Lessons learned
- L’auto-port-assignment Traccar n’est pas documenté — le mapping dépend de la version du JAR et change entre releases sans warning
<protocole>.portdans traccar.xml force le binding sur un port précis — c’est la seule manière fiable de garantir un port stable pour un protocole donné<protocole>.enable=falsedésactive complètement un protocole — utile pour libérer un port que tu veux réutiliser- Nom de protocole = nom de classe Java en lowercase, sans suffixe
Protocol:Jt808Protocol→jt808. Vérifier en cherchant la classe dans le JAR (unzip -l tracker-server.jar | grep ProtocolClass) - Lister les classes Protocol du JAR :
unzip -l tracker-server.jar 2>/dev/null | awk '/Protocol\.class$/ {print $NF}'— donne tous les protocoles disponibles dans cette version