A1：confirm the access address and port are correct.

The most common issue is an incorrect server IP or port (e.g., confusing public/private IP, mistaking the custom port set during installation. The default Web port is 80, the Link port is 50000).Format is ‘http://SERVER_IP:[PORT]’.

A2.：Check if the network between the server and the local computer is connected.

On the local computer’s terminal, execute ping server_IP (works for Windows/Linux). If it shows “Request timed out,” the network is unreachable. For intranet scenarios, confirm the computer and server are on the same subnet. For external access scenarios, check if the server’s public IP can be pinged normally, or contact the ISP to confirm the public IP configuration.

A3： Confirm if the KiloLink Server Pro service started normally.

The server service did not start or stopped unexpectedly, causing access failure. Log in to the server terminal and execute docker ps (for container deployment scenarios). Check if the container with “kilolink-server” in its name shows a status of “Up”. If not started, execute docker start container_name to restart the service.

A4：Check if the server firewall or security group has the ports open.

 The server firewall (e.g., Linux firewall) or cloud platform security group (AWS/Aliyun, etc.) has not opened the Web port (e.g., 80) and device link port (e.g., 50000), which blocks access requests.Solution: Local Server: Execute ufw allow 80/tcp and ufw allow 50000/udp (Ubuntu system) to open the corresponding ports. Cloud Server: Enter the cloud platform console, add rules in the “Security Group” configuration to allow ports 80, 50000, and other required ports (refer to manual section 2.6 for port descriptions).

A1： Confirm the server IP, port, and authorization code are correct.

Check the authorization code on the server’s “Device Management -> Add Device” page. Confirm the “Server IP” filled in on the device is the server’s public/private IP, and the “Service Port” matches the “Link port” from the server deployment (default 50000, must be an even number).

A2：Check if the device and server versions are compatible.

The firmware version of P-series devices is incompatible with KiloLink Server Pro (e.g., older device firmware does not support the new server’s aggregation protocol). It is recommended to upgrade both P-series devices and KiloLink Server Pro to the latest versions available on the official website.

A3：Confirm port forwarding is configured correctly (device in external network scenario).

If the device and server are not on the same LAN, lack of port forwarding on the server will prevent the device from connecting. Solution: Log in to the router of the server’s network, go to “Port Forwarding” settings, and add a rule: – External Port / Internal Port both fill in the server’s Link port (e.g., 50000). – Internal IP fill in the server’s local private IP (check using the ip addr command). – Protocol select “UDP”. Save and restart the router for testing.

A1：Check if the port is occupied by another program.

Default ports like 80 (Web) and 50000 (device link) might be occupied by programs like Apache, Nginx.Solution: Log in to the server terminal, execute netstat -tuln | grep port_number (e.g., grep 80), check if a process is occupying the port. If yes, note the Process ID and execute kill -9 Process_ID to stop the occupying program.

A2：Reconfigure to use an unoccupied port.

If the program occupying the port cannot be stopped (e.g., essential system service), the server port needs to be changed.Solution: Re-run the deployment script. During the “Web port” or “Link port” configuration steps, enter an unoccupied port (Link port must be even). After deployment, ensure the firewall also opens the new port. The device end must also be filled with the new Link port.

A1：Check if the server memory meets the minimum requirements.

Insufficient server memory (e.g., only 2GB RAM but bonding service is enabled) can cause high resource usage and unstable service (Bonding service requires 4GB+ RAM). Solution: Log in to the server terminal, execute free -h to view memory usage. If free memory is consistently below 1GB, upgrade the server memory to 4GB or more. If upgrade is not possible immediately, stop non-essential other services (e.g., systemctl stop irrelevant_service_name) to free up memory.

A2：Confirm if the server CPU core count meets the standard.

The bonding service requires a 2-core or higher CPU; a single-core CPU will lead to insufficient processing power, causing lag.Solution: Execute lscpu to check the number of CPU cores. If it’s 1 core, upgrade the server CPU configuration. Also avoid running other high-resource programs on the server (e.g., video transcoding, large databases).

A1：Check if the Ubuntu system version is too low.

The server Ubuntu version is lower than 20.04 LTS, Solution: Execute lsb_release -a to check the system version. If the version is too low, back up data and upgrade the system to 20.04 LTS or higher, or reinstall a compliant Ubuntu system before deploying the server.

A2：Confirm if the Docker version is compatible.

A Docker version that is too low may cause image pull or run failures (recommends Docker 24.0.5 or more).Solution: Execute docker –version to check the version. If lower than recommended, execute apt update && apt upgrade docker.io -y to upgrade Docker. After upgrading, restart the Docker service (systemctl restart docker).

A1：Check if the sub-account has been granted directory access permissions.

The admin has not assigned directory permissions to the sub-account, causing the sub-account to be unable to view devices under that directory.Solution: Log in to the server with the admin account, go to “Device Management -> Directory Management,” find the target directory, click “Access Control,” add the sub-account to the “Allow List,” select permission as “View and edit,” save, and have the sub-account log in again.

A2：Confirm if the sub-account has been granted individual device authorization.

Just assigning directory permissions is not enough; specific devices need to be authorized individually for the sub-account. Admin logs in, goes to “Device Management -> All,” finds the target device, clicks “Access Control” on the right, adds the sub-account to the allow list, and selects permission as “View and edit.” If the sub-account only needs viewing, select “View only.”

A3：Check if the sub-account belongs to the correct user group.

The sub-account has not joined an authorized user group, leading to missing permissions. Go to “User Management -> User Groups,” confirm the sub-account has been added to the target user group. If not, edit the user group and add the sub-account. Also ensure the user group has been granted system permissions (e.g., “Device Management” permission

A1：Check if the firmware file format is correct.

The uploaded file is not in .bin format, or it’s not the firmware for the corresponding device model (e.g., uploading E3 firmware for an N60 device).Solution: Confirm the firmware file has the .bin extension and the filename contains the device model (e.g., “firmware-N60-kiloview-2.02.0020.bin”). If the format is wrong, download the correct firmware for the device from the Kiloview website.

A2：Confirm if the logged-in account has upload permissions.

The sub-account does not have “Firmware Management” permissions; only admin does by default. Login with the admin account to upload. If a sub-account needs to operate, go to “User Management -> User Groups,” assign the “View/Edit” permission for “Firmware management” to the sub-account’s group.