Hong Kong servers, with their superior international network, low latency to mainland China, and abundant data center resources, have become the preferred choice for many enterprises deploying websites, applications, and acceleration services. However, with business growth and increased network exposure, bandwidth theft or hijacking is becoming more common. This can range from minor issues like bandwidth saturation leading to slow access to serious problems like skyrocketing bills, server downtime, and even ISP blocking. Bandwidth hijacking is not an isolated incident; it can stem from malicious scanners making large requests, hotlinking resources, DDoS traffic, proxy exploitation, malicious script injection, or internal configuration errors. To truly resolve the issue, it's essential to understand the principles of hijacking, its identification methods, and continuous defense strategies.

　　The most typical signs of bandwidth theft usually include: a sudden spike in outbound bandwidth from the server, but with relatively low levels of normal business traffic in the access.log; normal server CPU and memory load, but extremely high outbound traffic; continuous bandwidth consumption during off-peak hours; abnormally slow access from Hong Kong servers to mainland China; and an unusually high bill. This situation often indicates that the server is transmitting large amounts of data outbound, and this data is not from normal user requests, but rather that someone is exploiting the outbound bandwidth in some form.

　　The first step in identifying bandwidth hijacking is to check real-time bandwidth usage. The following commands can be used to analyze the source of external connections:

iftop -nNP

　　This tool can display in real time which IP is consuming bandwidth. When you see a large number of downloads of a resource continuously coming from a single IP or an abnormally distributed range of IPs, it's likely that the resource is being hotlinked or the API is being exploited. Further use with nethogs to view specific process usage:

nethogs

　　If you find that bandwidth is primarily being consumed by nginx, php-fpm, or a suspicious process, you can determine that bandwidth is being abused, rather than a problem with the system itself.

　　The second step is to check the server logs, including nginx logs, application interface logs, and server system logs. For example, check nginx's access.log:

tail -f /var/log/nginx/access.log

　　Pay close attention to the following characteristics: a large number of GET requests from the same IP address; request URLs concentrated on high-traffic resources such as images, videos, ZIP files, or static files; request status codes of 200 or 206, indicating a normal response; User-Agent being a crawler, proxy, empty UA, or abnormal UA; and requests originating from areas outside the normal business user zone. These are typical signs of resource hotlinking. If requests are concentrated on a specific API interface, it indicates that the interface has been exposed and is being exploited, potentially causing the server to continuously return JSON, files, or even database content, thus continuously consuming bandwidth.

　　Once the problem is initially identified, the next step is to implement protection measures for different types of hijacking. For hotlinked resources, the most direct method is to enable anti-hotlinking policies. For example, in nginx, the following configuration can be added:

location ~* \.(jpg|jpeg|png|gif|mp4|zip)$ {
    valid_referer none blocked example.com *.example.com;
    if ($invalid_referer) {
        return 403;
    }
}

　　This configuration prevents third-party websites other than this site's domain from referencing resources, thus reducing bandwidth consumption from hotlinking. For API attacks, access frequency limits can be added, for example:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=30r/s;

location /api/ {
    limit_req zone=mylimit burst=20;
}

　　This effectively prevents malicious web crawlers and attack scripts from sending a large number of requests in a short period of time, consuming network resources.

　　If bandwidth hijacking originates from an abnormal IP address, it can be quickly blocked using a firewall, for example:

iptables -A INPUT -s 1.2.3.4 -j DROP
iptables -A INPUT -m state --state NEW -m recent --update --seconds 1 --hitcount 50 -j DROP

　　Alternatively, use fail2ban to automatically block repeat visitors, thus achieving dynamic protection.

　　Hong Kong servers, due to their user-friendliness to overseas users, are sometimes used as proxy nodes. Malicious users may exploit vulnerabilities, weak passwords, or open ports to turn the server into a jump server for external network communication, leading to bandwidth saturation. This situation can usually be investigated by checking for: abnormal processes consuming bandwidth; checking for open proxy ports, such as 1080, 8080, and 3128; and checking SSH login records for suspicious foreign IP addresses.

cat /var/log/auth.log | grep "Failed password"

　　If numerous brute-force attempts or successful logins are detected, it indicates a risk of account theft on the server. Passwords should be changed immediately, SSH keys enabled, and ports and login sources restricted.

　　Another type of bandwidth hijacking occurs when malicious JavaScript is injected into a webpage. Attackers exploit this by loading high-bandwidth external resources or cryptocurrency mining programs, causing continuous bandwidth consumption for visitors. This often occurs when web pages are compromised or CMS systems have vulnerabilities. The solution is to use file integrity verification tools on the server or scan project files for tampering.

grep -R " 

　　For PHP programs, check for abnormal code snippets such as base64 encryption and `eval` statements. If abnormal files are found, clean them up promptly and strengthen program vulnerability patching.

　　For more advanced bandwidth hijacking, which may involve link hijacking—for example, a visitor's request being redirected to other content, the user seeing content inconsistent with reality, or abnormally high bandwidth—these issues may involve ISPs or upstream links. Hijacking points need to be reduced through TLS encryption, mandatory HTTPS, and CDN site-wide acceleration. Using HSTS, disabling HTTP degradation, and enabling HTTPS for all static and dynamic content can significantly reduce the risk of content being tampered with or inserted into the link.

　　After addressing the problem, it's crucial to establish a long-term defense mechanism, rather than scrambling to react when the next anomaly occurs. A high-quality bandwidth protection strategy should include the following: configuring bandwidth monitoring and using vnstat to view daily traffic changes; caching frequently accessed interfaces to reduce origin server requests; enabling CDN anti-hotlinking and hiding the origin server IP; hosting large files in object storage to reduce server outbound pressure; setting up WAF to block abnormal requests; and regularly checking login records, firewall policies, and open ports. Through multi-layered protection, the risk of bandwidth theft from Hong Kong servers can be minimized.

　　In the long run, preventing bandwidth hijacking is not just a technical issue, but a fundamental aspect of security operations. Once a server is exposed to the public internet, it is vulnerable to malicious use. Attackers, hotlinkers, web crawlers, or unauthorized proxies can all consume large amounts of bandwidth without your knowledge. Understanding the source of network traffic, real-time monitoring of bandwidth changes, strengthening access control, and establishing comprehensive protection strategies are essential to ensure that Hong Kong server bandwidth always serves genuine business needs and does not become someone else's resource.