Online Account Bans in Web Services: Risk Control Causes and Prevention Practices

1. Why accounts get flagged by risk control

Many users attribute bans to bad luck or being targeted after payments. From a system implementation perspective, most bans come from decisions made by automated risk control engines. These engines do not primarily ask whether someone is a real user; they ask whether the behavior sequence matches what a normal user is expected to do. Common triggers include:

• Abnormal login behavior sequences, such as unusual timing, frequency, or geographic jumps;
• Unstable network egress, such as a low-quality or low-reputation IP;
• Device fingerprints changing frequently over a short period;
• The same identity being active in multiple locations or on multiple endpoints at the same time.

The key point is that risk control is evidence-chain-driven. A single action may not be fatal, but multiple weak signals stacked together can produce a high-risk score and trigger a block.

2. Core technical causes

1) Geographic drift and impossible travel detection

A common and easily overlooked risk-control check is Impossible Travel. If the same account appears to log in from one country or city and then “teleports” to another location that could not be reached in that time, it is marked as high risk. This is often associated with account takeover or proxy abuse.

The detection logic is essentially a distance/time estimation:

# Example: impossible travel detection based on spherical distance
def haversine_km(lat1, lon1, lat2, lon2):
    # Calculate spherical distance between two coordinates (km)
    ...
    return distance_km
def detect_impossible_travel(events, max_speed_kmh=1000):
    # events: time-sorted list of objects with ts, lat, and lon
    for prev, curr in zip(events, events[1:]):
        gap_h = (curr.ts - prev.ts).total_seconds() / 3600
        dist = haversine_km(prev.lat, prev.lon, curr.lat, curr.lon)
        if gap_h > 0 and (dist / gap_h) > max_speed_kmh:
            return True   # excessive distance in a short time -> high risk
    return False

In other words, “the user is still in one place, but the login IP jumps back and forth across distant locations” is a high-risk scenario.

2) Inconsistent egress IP: a real leak signal

A useful real-world example is the case where the same proxy node shows the same address across three layers on a desktop—application layer, DNS layer, and tunnel layer—but shows three different addresses on a phone. This indicates address leakage: part of the real egress is exposed to the server.

A single login request may pass through multiple network layers, and each layer may expose a different egress:

• HTTP/application egress: the source IP when calling business APIs;
• DNS resolution egress: the egress used when resolving domains;
• P2P/real-time communication egress, such as candidate addresses used in traversal, which may expose the local or ISP egress.

If these layers report geographically contradictory locations, the risk-control side sees a session whose source addresses contradict one another. This is more suspicious than a simple IP change. The following self-check script illustrates the idea:

# Example: multi-layer egress consistency check (addresses use neutral placeholders)
# 1) Application-layer egress IP
curl -s "https://<public-ip-echo-service>/ip"
# 2) DNS-layer egress IP using a public DNS that can echo the egress
dig +short +short @<public-dns-host> whoami.<echo-domain>
# 3) Real-time communication egress: check whether ICE candidate addresses match the above

If the three layers point to different geolocations, the network configuration likely has a leak, and it should be fixed first.

3) Device fingerprint and multi-device login conflicts

Risk control also collects device fingerprints: User-Agent, screen resolution, timezone, font list, Canvas/WebGL characteristics, concurrent sessions, and more. The pattern of “log in on a computer, then log in on a phone, then switch browsers” creates two types of signals:

• High-frequency fingerprint changes: multiple device profiles appear in a short time, resembling one person controlling many accounts or bulk registration;
• Concurrent or chained logins: login events occur densely in a short time and may be treated as automated script behavior.

A particularly risky case is logging in from a phone immediately after adding funds. A new account has low weight and the highest sensitivity to risk-control rules, so multi-device or multi-point login at this stage is very likely to increase the risk score.

4) Network egress quality and IP reputation

Risk-control systems usually maintain IP reputation databases. Datacenter IPs, heavily shared proxy egress addresses, and addresses frequently appearing on blocklists naturally receive higher risk weights. Even if a node seems clean to you, it can still be associated with risk if it belongs to a high-risk subnet or is shared by many accounts.

3. Practical prevention practices

Based on the causes above, the following practical stability strategies can be summarized:

1. Keep network egress stable and avoid geographic jumps. Bind to the same node and the same geographic location for long-term use, and reduce cross-country or cross-city “teleporting.” This directly addresses impossible-travel detection.

2. Limit login devices and browsers. Do not frequently switch devices, browsers, or operating systems for the same account. If multiple endpoints are required, keep device fingerprints stable and avoid concurrent logins.

3. Be especially cautious with new accounts. Accounts that have just been registered or have just added funds have low weight. At this stage, multi-device and multi-location logins should be avoided. Let the account settle for a period and use a single stable environment first.

4. Run egress self-checks before use. Periodically check whether the application, DNS, and real-time communication layers show consistent egress addresses. If a leak is found, fix the network configuration promptly.

5. Isolate identities and environments. Accounts used for different purposes and different network environments should be isolated as much as possible to prevent risk profiles from contaminating each other.

4. From the perspective of system builders

If you are a platform or service provider, the pitfalls above can be reversed into a risk-control design checklist. A typical account risk-control system relies on a combination of general capabilities: unified identity authentication, log services that accumulate login and behavior records, monitoring and alerting for abnormal scores, and a scoring engine based on rules plus models.

For example, Baidu AI Cloud provides general cloud product categories such as log services, monitoring alerts, and identity authentication that can serve as underlying capabilities for building such risk-control and audit systems. Refer to the official documentation for specific capabilities; this article does not cover undisclosed interfaces or billing details.

5. Appeals and hidden costs

It is worth noting that appeals against automated risk-control false positives are often inefficient. The decisions are usually based on model scores rather than a single piece of hard evidence, making it difficult for human reviewers to overturn them quickly. Instead of appealing after a ban, managing environmental stability at the source is the lowest-cost, highest-return path.

Some services may refund the balance of a banned account, but this is an individual platform policy and should not be treated as a way to repeatedly try and fail.

6. Summary

Account bans may look different on the surface, but the underlying logic is consistent: risk control is checking whether you use the service like a real person, in a stable way, within the same environment. Stable egress, limited devices, leak self-checks, and restrained behavior on new accounts cover most individual-user ban scenarios. Treating risk control as a system to cooperate with rather than confront can significantly reduce account risk and support long-term stable use of online services.