Account Bans from LLM Services: Multi-Device Switching, IPv4/IPv6 Dual-Stack and WebRTC Leaks

1. The bottom line: account restrictions are an explainable engineering problem

Many developers who use overseas large language model (LLM) services eventually run into a restricted account. The restriction often comes after a top-up, a device change or a network configuration change. Public user reports suggest that appeals succeed fairly rarely, although payments are usually refunded through the original payment method when an account is banned by mistake. Because of this, many people write bans off as bad luck, or start looking for ways to “beat” risk control.

In reality, most bans have the same root cause: the account has left signals that contradict each other, or that change frequently, across three dimensions: network, device and behavior.

This article is about reducing false positives in normal use. Multiple accounts, shared accounts, bulk registration and any form of abuse are primary targets of risk control. No technical measure can get around that, and you should not try.

To reduce false positives, you first need to know what risk control looks at. Mainstream platforms generally score accounts across the following dimensions, and a single indicator rarely triggers a ban on its own:

• Network: the location of the login IP, its autonomous system number (ASN) and that ASN’s reputation history, proxy and datacenter address flags, and protocol stack information.
• Device: browser and operating system fingerprints, timezone, language and the number of concurrent sessions.
• Behavior: request frequency, the times of day when requests are made, and how well the payment method matches the account’s region.

The highest weight does not go to any single indicator. It goes to whether the signals across these dimensions are consistent with each other and stay stable over time. For one account, a usual login location that frequently jumps between continents, or device and network characteristics that keep changing, is more likely to trigger risk control than simply being in a particular region. With that in mind, every measure below follows the same logic.

2. Root cause 1: consistency and “cleanliness” of the egress IP

2.1 Three common misconceptions

Misconception 1: if the proxy client shows “connected,” the egress IP is fine.
Modern operating systems and browsers use “Happy Eyeballs” by default, which means they open IPv4 and IPv6 connections at the same time and use whichever one completes first. If the proxy only handles IPv4 traffic, IPv6 traffic bypasses the proxy and leaves directly through the local broadband connection. The same account is then accessed from two addresses in different locations. The classic example is “the computer works fine, but the phone gets banned.” In testing, the same node reported identical IPv4, IPv6 and WebRTC public addresses on a computer. On a phone, the three addresses belonged to different networks.

Misconception 2: an overseas node IP is automatically “clean.”
Proxy providers commonly use shared address pools. A single egress IP may serve hundreds or thousands of users at the same time, including people who bulk-register accounts or run scripts to abuse the service. These addresses build up a poor record in IP reputation databases over time and are often flagged as datacenter or proxy exits. Even if your own account behaves impeccably, its score can be pushed up by a poor exit reputation.

Misconception 3: random rotation of the address pool counts as “IP protection.”
Some providers advertise “dynamic residential IPs,” but in practice they assign an address at random from a huge pool for each connection. That can be useful when privacy is the main concern. However, from a risk-control perspective, one account moving back and forth between multiple countries and carriers within a single day is exactly the most dangerous behavior pattern.

2.2 Self-check: turn “it seems fine” into “the data proves it”

To judge whether your network setup is sound, check these four things:

• the IPv4 egress address;
• the IPv6 egress address (if the device supports it);
• the public address that the browser detects through WebRTC;
• the exit location of the DNS resolver currently in use.

In principle, the first three should point to the same exit. If the DNS resolver exits from a different region, that is a “local inconsistency.” Its impact is smaller, but it is still best to keep it aligned.

Check the IPv4 and IPv6 egress.
Visit two endpoints that only echo back the IP address of whoever connects to them. One accepts IPv4 only, and the other accepts IPv6 only. You can do this from the command line or with the Python standard library. (The domains in the examples are documentation placeholder domains. Replace them with the addresses your provider gives you.)

# Each check should return exactly one address for the IPv4 and IPv6 egress respectively
curl -4 -s https://<endpoint-a-domain>/ip
curl -6 -s https://<endpoint-b-domain>/ip

import json, socket, urllib.request
def fetch(url, family, timeout=10):
    """Request a URL using a specific address family and return the response body."""
    saved = socket.getaddrinfo
    # Temporarily restrict the address family so the system doesn't switch between IPv4 and IPv6
    socket.getaddrinfo = lambda *args, **kwargs: saved(family, *args, **kwargs)
    try:
        with urllib.request.urlopen(url, timeout=timeout) as resp:
            return json.load(resp)
    finally:
        socket.getaddrinfo = saved
v4 = fetch("https://<endpoint-a-domain>/ip", socket.AF_INET)
v6 = fetch("https://<endpoint-b-domain>/ip", socket.AF_INET6)
print("IPv4 egress:", v4)   # Expected: {"ip": "203.0.113.10", "country": "US"}
print("IPv6 egress:", v6)   # Expected: same network as IPv4; fails if the device doesn't support IPv6

Check for WebRTC leaks.
WebRTC is a real-time communication standard built into browsers. To set up peer-to-peer connections, the browser asks a STUN server, through the ICE framework, for “its own mapped address on the public internet.” If UDP traffic isn’t routed through the proxy, that address reveals the real public exit of the local network. The script below can be run directly in the browser console:

// Collect ICE candidates: "host" is an internal address, "srflx" is the public address mapped by STUN
const pc = new RTCPeerConnection({ iceServers: [{ urls: "stun:<stun-server-domain>" }] });
const leaked = new Set();
pc.createDataChannel("probe");
pc.onicecandidate = e => {
  const m = e.candidate?.candidate.match(/^candidate:\S+ \d+ (?:udp|tcp) \d+ (\S+)/);
  if (m) leaked.add(`${e.candidate.type ?? "?"} ${m[1]}`);
};
pc.createOffer().then(o => pc.setLocalDescription(o));
setTimeout(() => { console.table([...leaked]); pc.close(); }, 3000);
// Verdict: if the srflx address differs from the IPv4 egress found via the command line, UDP traffic isn't going through the proxy

Judge whether an address is “clean.”
Once you have the egress address, look up which carrier owns it and what type of address it is. The common criteria are:

• If it belongs to a major cloud or hosting provider, it is a “datacenter IP,” which usually gets a higher risk score than a residential broadband IP.
• If IP reputation databases flag it as a proxy, VPN or Tor exit, the risk is higher still.
• If the same address has already been used by a large number of unfamiliar accounts, it comes from a shared address pool.

2.3 Key principle: a “sticky” egress matters more than a “clean” one

Within the options available to you, staying stable matters more than being cleaner. The ideal setup is a long-term one-to-one mapping of “account → device → egress address,” so that an account always logs in from the same device and the same network exit. If your provider can keep a fixed egress for a given node session, turn that on. That way, each connection won’t be assigned a different address. When possible, you can also choose a dedicated egress.

The example code below shows a common approach. Once a connection is up, recheck the egress address at regular intervals. If it has changed, disconnect and reconnect immediately, and send an alert.

import hashlib, json, time
def egress_fingerprint():
    info = fetch("https://<endpoint-a-domain>/ip", socket.AF_INET)
    raw = json.dumps(info, sort_keys=True).encode()
    return hashlib.sha256(raw).hexdigest()[:16]
def watch_egress(interval=1800, on_drift=None):
    """Recheck the egress fingerprint every interval seconds and call back when it changes."""
    baseline = egress_fingerprint()
    while True:
        time.sleep(interval)
        current = egress_fingerprint()
        if current != baseline:
            on_drift and on_drift(baseline, current)
            baseline = current

This approach, “record a baseline first, then compare against it continuously,” is far more reliable than checking manually once in a while. It is also the foundation for the automated checks described later.

3. Root cause 2: drift in devices and login behavior

3.1 Why logging in from multiple devices is risky

Risk control doesn’t care how many devices you have used. What it watches is how often the same account switches back and forth between devices and networks. Each device has its own browser fingerprint (User-Agent, timezone, language, fonts, screen parameters and so on) and its own network exit. When you log in and out on a computer, then log in on a phone, risk control effectively sees one account being accessed from multiple locations and multiple devices within a short period. If those devices happen to use different nodes, or if some of their traffic goes out directly, the conflicting signals are amplified many times over.

3.2 Mobile devices are the biggest risk area

The risks on mobile come from three sources:

1. The egress is unstable by nature: cellular networks assign addresses dynamically per cell tower, so switching towers or toggling airplane mode can change the IP.
2. Proxy coverage is incomplete: on phones, many proxy apps only handle application-layer requests by default, while lower-level traffic such as WebRTC and IPv6 still leaves through the local network.
3. The usual entry points keep changing: the network environment changes between commuting, home and going out, which makes a stable egress baseline hard to establish.

So if your main environment is a computer, try not to let your phone become a regular login entry for the same account, and never have both devices online at the same time.

3.3 Risky behavior vs. recommended practice

Risky behavior	What risk control sees	Recommended practice
Taking turns logging into the same account from several computers and browsers	Browser fingerprint and IP location change frequently	Stick to one primary device and one browser configuration
Computer and phone online at the same time	Two concurrent sessions, each with its own egress	Keep only one active session at a time
Using different nodes for the same account	Login location jumps between countries and carriers	Use one node and enable session persistence
Using a node with rotating addresses	The account’s address keeps drifting	Choose a fixed egress or bind a dedicated egress
Proxy set to cover only some applications	IPv6, WebRTC and other traffic bypass the proxy	Use system-level or TUN mode to route all traffic
Large subscription right after registration	Payment behavior that doesn’t fit a new account	Start with a small trial and upgrade after a period of stable use
One payment method linked to many accounts	Triggers correlation checks on the payment dimension	Keep payment details in one-to-one correspondence with accounts

It is worth stressing that “stay fixed” does not mean “never change.” When you travel or move, network changes are unavoidable. What matters then is to use the usual environment stably for a while before the change, and to keep the new environment stable afterward, instead of switching back and forth every day.

4. Hardening the account and network as a whole

Reducing false positives takes work on three levels at once: network, device and account.

• Network: unify the egress, fix the region, route all traffic and run regular checks.
• Device: keep the device and browser configuration fixed, and limit concurrent sessions.
• Account: keep your information consistent, move forward gradually, and don’t stake critical data on a single service.

4.1 Hardening the network layer

1. Fix the region and the node. Choose a node in the same region as where the account was registered and where you usually log in. Use it long-term and don’t switch on a whim.
2. Route all traffic through one exit. Prefer system-level or TUN mode so that TCP, UDP, IPv4 and IPv6 traffic all go through the same exit. Also turn off IPv6 on devices that don’t need it, which removes the dual-stack split caused by Happy Eyeballs.
3. Keep DNS aligned with the egress. Use encrypted DNS resolution in the same region as the egress, so DNS traffic doesn’t leave from your local network.
4. Set up automated checks and alerts. Add the egress checks described in Section 2 to a scheduled task so you get an alert as soon as a change is detected. On Linux, you can start with crontab:

# Run the egress check every 30 minutes
*/30 * * * * /usr/bin/python3 /opt/checks/egress_guard.py

The check script can use two baselines, the egress fingerprint and the region. If either one changes, the script writes a log entry and sends a notification through an alerting channel:

#!/usr/bin/env python3
"""Egress drift check: prints an alert line only when something is wrong, for log systems to collect."""
import json, sys, urllib.request
from datetime import datetime, timezone
BASELINE_FILE = "/opt/checks/baseline.json"
ALERT_WEBHOOK = "<alert-webhook-url>"   # A cloud messaging service or a custom webhook service works
def info(url, family=socket.AF_INET):
    data = fetch(url, family)
    raw = json.dumps(data, sort_keys=True).encode()
    return hashlib.sha256(raw).hexdigest()[:16], data.get("country", "?")
def notify(text):
    req = urllib.request.Request(
        ALERT_WEBHOOK,
        data=json.dumps({"text": text}).encode(),
        headers={"Content-Type": "application/json"},
    )
    urllib.request.urlopen(req, timeout=5)
def main():
    fp, region = info("https://<endpoint-a-domain>/ip")
    try:
        with open(BASELINE_FILE, encoding="utf-8") as f:
            baseline = json.load(f)
    except FileNotFoundError:
        baseline = {"fingerprint": fp, "region": region}
        with open(BASELINE_FILE, "w", encoding="utf-8") as f:
            json.dump(baseline, f)
    if fp != baseline["fingerprint"]:
        msg = (f"Egress drift: {baseline['region']} → {region} "
               f"({baseline['fingerprint']} → {fp})")
        print(json.dumps({"ts": datetime.now(timezone.utc).isoformat(),
                          "level": "WARN", "msg": msg}, ensure_ascii=False))
        notify(msg)
        sys.exit(1)
    print(json.dumps({"ts": datetime.now(timezone.utc).isoformat(),
                      "level": "INFO", "msg": "Egress normal"}))
if __name__ == "__main__":
    main()

If you have several machines to check, send the results to a log service for centralized search. Then set up threshold-based notifications in your monitoring and alerting. This makes past events easy to trace back and anomalies easy to spot as they happen.

4.2 Hardening the device layer

• Use one primary computer and one primary browser, kept in a dedicated browser profile directory.
• Give each account its own isolated browser profile so accounts don’t contaminate each other.
• From time to time, remove devices and login sessions you no longer use in the platform’s security settings.
• Keep your timezone and language consistent with the region of your usual egress to reduce “conflicting signals” in your fingerprint.
• Avoid extensions that change the User-Agent or randomize fingerprints. They make the same device present a different “identity” at different times, which creates new inconsistencies.

4.3 Hardening the account layer

• Keep your profile consistent: try to keep the country of your registration email, phone number and payment method aligned with your usual egress region to reduce cross-dimension conflicts.
• Move forward gradually: start a new account with the free tier or a small trial, and upgrade to a paid plan only after your network and device are stable. Registering, topping up and logging in from everywhere right away is exactly the most dangerous combination.
• Keep credentials off the client: store keys only in server-side credential management or a key management service. Frontend applications should forward requests through your own backend instead of hardcoding keys on the client. And don’t commit keys to code repositories in personal projects.

5. If your account is restricted: limit the damage, appeal, and protect yourself long-term

5.1 Stop risky behavior right away

As soon as you receive a restriction notice, stop all login attempts. Retrying frequently only adds more abnormal signals and can make an appeal even harder.

5.2 Gather evidence and appeal through official channels

Collect your account registration details, a description of your usual devices and network environment, records of normal usage and billing, and a record of recent changes, such as switching nodes or devices. Submit them through the platform’s official support channel. Many platforms refund fees through the original payment method once they determine a ban was a mistake, but the overall success rate is not high, so keep your expectations realistic.

5.3 Treat reliance on a single vendor as a technical risk

Architectural safeguards matter more than appeals. Don’t put your critical business entirely on one overseas service account. A common industry practice is to put a unified gateway between your application and model services, so that “which service to use” becomes configurable, degradable and replaceable:

type ChatRequest = { prompt: string; temperature?: number };
interface ModelProvider {
  readonly id: string;
  chat(req: ChatRequest): Promise<string>;
}
class ModelGateway {
  // Order defines priority: primary → backup → regional fallback
  constructor(private providers: ModelProvider[]) {}
  async chat(req: ChatRequest): Promise<string> {
    const errors: string[] = [];
    for (const p of this.providers) {
      try {
        return await p.chat(req);
      } catch (err) {
        errors.push(`${p.id}: ${(err as Error).message}`); // Log it and try the next one
      }
    }
    throw new Error(`All providers failed → ${errors.join(" | ")}`);
  }
}

With this abstraction in place, your application can switch providers automatically when one account is restricted, instead of grinding to a halt. And if your use case doesn’t depend on models or context capabilities unique to overseas services, using a large model service from a regional cloud provider such as Baidu AI Cloud is often simpler and more stable. It also sidesteps most of the problems described above involving cross-border networks, devices and egress stability.

6. Pre-launch checklist

1. Does the account always log in from your primary device and primary browser?
2. Is only one session active at any given time?
3. Are the egress addresses (IPv4, IPv6 and WebRTC) consistent and stable over the long term?
4. Does the proxy route all traffic in system-level or TUN mode?
5. Does the node have session persistence enabled, or a dedicated egress assigned to it?
6. Is DNS resolution in the same region as the egress?
7. Are your account details, payment method and usual region consistent?
8. Have you set up egress drift checks and alerts?
9. Are keys stored only on the server and called through a unified gateway?
10. Do you have a backup provider and a fallback strategy?

7. Conclusion

A banned account may seem to happen out of nowhere, but you can almost always trace it back to explainable conflicting signals: a jumping egress address, IPv4/IPv6 dual-stack and WebRTC leaks, frequent switching of devices and networks. These are engineering problems that can be measured and addressed systematically. Harden your setup around four principles: consistent egress, stable egress, fixed devices and consistent behavior. Combine them with automated checks and alerts, and with a unified gateway that keeps you portable. Together, these turn occasional bans from an uncontrollable risk into a manageable problem.

One more reminder: the methods above are only for legitimate, normal personal use, and their purpose is to reduce false positives. Any attempt to get around platform rules, bulk-register accounts or otherwise abuse the service violates the terms of service and is not compliant.