Bypassing DeepSeek Detection: Sneaky Reverse-Proxy Tricks to Avoid Bans and Their Risks

The Reverse-Proxy Ban Dilemma and the Lure of "Unlimited Tokens"

Recently, a Bilibili creator shared a reverse-proxy scheme for "unlimited DeepSeek^Ad tokens without getting banned," with a rather eye-catching video title—"Unlimited Tokens! Big Fat Fish All You Can Eat!" According to the creator, he figured out this method only after getting 20 accounts banned. The core idea isn't traditional high-concurrency tool invocation, but rather evading DeepSeek's risk-control detection logic.

So-called "reverse proxying" means routing the official API or web interface through a self-built relay service, distributing the shared model capability to multiple users, and thereby achieving a near-"unlimited" token consumption experience. This approach isn't new in the community, but it has long faced a fatal problem: accounts get banned in batches. The creator's practical value lies in trying to answer the key question: "What exactly does DeepSeek use to identify reverse proxying?"

Reverse proxy here refers to building a relay service that forwards requests to the official API or web interface and then distributes the model capability of a single account to multiple users. Its difference from regular API calls is that the caller doesn't directly hold an official key but shares the quota of the same upstream account. Since the official service bills and rate-limits by account or by token, reverse proxying essentially "amplifies" a single account's quota for multiple users, which is why it's often packaged as "unlimited tokens." Such schemes have long existed in technical communities, but platforms generally treat them as abuse that violates the terms of service, identifying and banning them through request characteristics, call frequency, account origin, and other dimensions.

Breaking Down the Detection Logic: XML Tags and Tool-Calling Features Are Key

According to the video, DeepSeek's main basis for identifying reverse proxying is the XML tag features in requests, especially the obvious markers left by traditional function calling. The creator's judgment is that the official risk control scans the request body for structured tags in specific formats, and once matched, determines it's a non-normal client call.

His countermeasure is quite "backyard-engineering": instead of traditional tool-calling tokens, use just a short English word as the trigger word. The video mentions using the word "Do." The logic is straightforward—if risk control only watches for XML tags and tool-calling formats, then an ordinary English word shouldn't be blacklisted, otherwise normal English-speaking users would be caught in the crossfire.

The creator also made an analogy: if detection were so strict that "saying one English sentence gets you banned," wouldn't foreigners using DeepSeek be as stuck as Chinese people using Claude? Although crude, the analogy points to a real contradiction—the coarser the risk-control rules, the greater the collateral damage.

Function calling is a structured interaction capability of large models: developers pre-declare several functions and their parameter schemas, and the model outputs structured content conforming to the agreed format when needed (commonly JSON or XML tags wrapped in a specific markup language), which the client parses, executes the real function, and returns the result. Because this format is highly templated, fixed tag names, field names, and nested structures appear in the request body, making it easy for risk-control systems to use as a fingerprint of a "non-ordinary chat client." That's precisely why reverse-proxy schemes tend to abandon full tool-calling capability and switch to natural-language trigger words to drive the flow, making the request body look closer to ordinary user chat.

Regional Restrictions on Email Registration and Integration Results

Beyond request characteristics, account origin is also part of risk control. The video mentions that DeepSeek supports email registration, but as long as the email/region isn't mainland China, it's fine. This suggests the official service already differentiates by region at registration, and accounts registered with overseas emails may be subject to different risk-control strategies.

After integrating with Harness, the creator demonstrated the actual effect: a "little machine" indicator appeared in the interface, and the request format became correct. His takeaway was that as long as the model doesn't frequently output DML, you won't get banned. DML here most likely refers to some specific markup-language output; frequent occurrences would be seen as an abnormal call pattern. The project address was placed in the video description, a typical "video traffic + open/semi-open source distribution" path.

Harness in such contexts generally refers to a frontend or orchestration framework that connects to large-model APIs, responsible for assembling user input into requests conforming to the official interface specification and managing sessions, model selection, and output parsing. When the creator says "after integrating with Harness, the request format became correct," he means the relay layer re-wrapped the request body according to the official protocol, making calls that might otherwise carry abnormal fields look like standard client behavior. The DML mentioned in the article isn't the Data Manipulation Language of databases; in context it more likely refers to some specific markup language or structured output format. If the model frequently outputs such fixed structures, it can easily be associated with tool-calling features and thus judged by risk control as an abnormal call pattern.

How Far Can This Scheme Go?

From a technical perspective, this reverse-proxy scheme's approach is "reducing features" rather than "improving performance": it doesn't pursue high concurrency or full tool-calling capability, only making requests look like ordinary conversations. In the short term, it may indeed bypass rule-based risk control, but it has several unavoidable pitfalls.

First, rule-based confrontation is dynamic. Once the risk-control side updates its detection dimensions (e.g., adding behavioral frequency, request fingerprints, output pattern analysis), simply changing trigger words will quickly fail. The creator's experience of "getting 20 accounts banned" itself shows that trial-and-error costs are high.

Second, account stability is questionable. Accounts that rely on overseas email registration and evading detection can be cleaned up in batches at any time. Building production or learning workflows on such accounts has a poor risk-reward ratio.

Third, the compliance boundary is blurred. Relaying official interfaces to multiple users is itself likely a violation of the terms of service; even if technically feasible for now, it isn't suitable for promotion as a long-term solution.

For ordinary developers, a more pragmatic approach is to pay attention to official pricing and quota policies, or choose legitimate third-party API aggregation services. Reverse-proxy "unlimited tokens" sounds great, but it's essentially a race against platform risk control—no matter how fast you run, there's always a day when you get caught.

One-line Summary

A Bilibili creator shares reverse-proxy ideas for evading DeepSeek bans—essentially a confrontation with platform risk-control rules.

Paragraph Summary

The article centers on a reverse-proxy scheme shared by a Bilibili creator for "unlimited DeepSeek tokens without getting banned." After getting 20 accounts banned, the creator concluded that DeepSeek's risk control mainly scans requests for XML tags and traditional tool-calling features, so he abandoned structured tool calling and switched to a single English word (like "Do") as the trigger, reducing the request's structured features; at the account level, he uses non-mainland-China emails to evade regional restrictions, and after integrating with Harness the request format normalizes—he claims that as long as the model doesn't frequently output DML, you won't get banned. The article points out that this scheme is about "reducing features" rather than "improving performance," and faces three hidden risks: dynamically updated risk-control rules, poor account stability, and violation of the terms of service—making it unsuitable as a long-term solution.