Server Troubleshooting

If you have problems with connecting your device to the server please follow the steps below.

Follow device data from tracker to network, server port and decoder, checking each stage to locate a connection problem.
1 Find device messages in the logs

Check tracking server logs:

  • On Linux and Mac it should be in /opt/traccar/logs
  • On Windows it's usually in C:\Program Files\Traccar\logs

If the server receives any data from the device (even if the port is wrong), you should be able to see incoming messages in the log. Depending on the protocol, a message is logged either as a HEX string (for binary protocols) or as readable text (for text-based protocols). If you see any incoming messages from the device in the log, go to point 2. If there are no messages in the log, go to point 4.

2 Check if messages are decoded

If there are incoming messages in the logs, you need to check the following things:

  • If messages are followed by an Unknown device warning, then it means that you haven't registered a device on the server. To fix this issue, add a device with the unique ID you see in the log through the web console.
  • If messages are followed by an INFO record with coordinates, then it means that data is decoded correctly. You might need to wait a little while for the device to show up in the web console.
  • In any other case proceed to point 3.
3 Investigate why messages are not decoded

There are two main possibilities:

  • Your device doesn't send GPS location. One of the reasons might be that it doesn't have a GPS fix. Note that GPS doesn't work indoors and it can take up to 15 or more minutes for the device to get a first fix. Be patient.
  • You are using the wrong port. Proceed to point 5.
4 Investigate why server does not receive data

If you don't see any message from the device in the log, it means that the server doesn't receive any data from your device. Possible reasons:

  • The server is not reachable using the device's configured port and transport. For TCP protocols, use the port check tool. It cannot test UDP ports. For UDP protocols, check the UDP listener and firewall rules, then inspect incoming traffic as described in point 6.
  • The device is configured incorrectly, or there is some problem with the device. Contact your device vendor for more information.
5 Find correct port for your device

Please read the following information:

  • If you are using Traccar Client, the default port is 5055.
  • If you are using a Chinese device, you must read about clones.
  • For all other devices, please read protocol identification guide.
  • If you were unable to identify the port for your device, please contact support. You must provide protocol documentation and/or message samples (HEX or text). A link to a store listing or user manual for a device is not sufficient.
6 Make sure required ports are open

First, check if Traccar is running and listening on the required ports:

  • On Linux, inspect TCP listeners with sudo ss -lntp and UDP listeners with sudo ss -lnup.
  • On Mac, use the netstat and ps command line tools.
  • On Windows, use Process Explorer.
  • For UDP traffic on Linux, use sudo tcpdump -ni any udp port 5055, replacing 5055 with your configured port. Incoming packets show that traffic reaches the host; check the logs to confirm Traccar decodes it.

For TCP, a failed external port check despite a local listener suggests a bind-address, firewall, routing, or port-forwarding problem. A TCP test does not establish whether a UDP listener is reachable. It's impossible to cover every possible network problem, but here is a list of the most common issues you might want to check for:

  • The router is not configured to forward external ports to your server.
  • The firewall on your server or router is blocking connections.
  • You do not have a public IP address. Contact your ISP or IT department to confirm.