DNS 出口和代理 IP 不同，就一定泄漏了吗？

sparke deng — Tue, 06 Oct 2026 03:29:18 +0000

一个排障示例：网页出口已经变成代理地址，DNS 检测却显示另一个地区。看到这里就换代理，可能白忙一场。

网页出口和递归解析器出口本来就是两种地址。仅凭它们不相同，不能确认泄漏；数据库标出的地区也不等于解析请求实际经过的机房。

更有用的做法是对照预期：你是否要求域名解析也走代理？如果是，就在同一个浏览器、同一条线路下，先保存一次结果，再只修改代理客户端的远程解析设置，重新检测。不要同时更换线路和浏览器，否则变化很难归因。

我维护的 12ce DNS 检测页会通过浏览器请求新的测试域名，展示本站权威节点观测到的解析器出口。它不是读取你网卡里填写的 DNS 地址，也不能覆盖所有应用的解析行为。

如果没有观测到结果，先记为“未确认”，不要当成“没有泄漏”。真正要交给管理员的是：预期路径、修改的设置、前后出口和检测时间，而不是只有一张红色警告截图。分享前请删掉账号、密码和不愿公开的地址。

本文为站点维护者分享，示例并非客户实测记录，文字由 AI 辅助整理。

Conflicting IP reputation scores: what to check before replacing a proxy

sparke deng — Wed, 16 Sep 2026 02:31:03 +0000

One lookup says high risk. Another returns zero. Meanwhile, the service you actually need either works or gives you an error that explains very little.

Replacing the proxy feels like a quick way out. Sometimes it helps. But if the problem was an expired API credential, a cached result, or a failed page parser, you have paid to change the wrong thing.

Here is a troubleshooting sequence for separating those cases. It does not require any particular diagnostic website.

1. Check whether the lookup succeeded

Before interpreting a score, check the lookup itself. Keep the HTTP status, provider response, timestamp and cache status together.

Observation	What it establishes	Next step
Timeout or connection error	The lookup did not complete	Check connectivity and retry once after a short delay
HTTP 401 or 403 from the reputation API	That API request was rejected	Read the response; check credentials, permissions and access restrictions
HTTP 429	The service is limiting requests	Respect its retry instructions; check quota before retrying
HTTP 200 with an error or missing score	Transport succeeded, but no usable score was returned	Check the API success field and response format
Valid score from a cached response	A result exists from an earlier lookup	Compare its age with the current failure before spending another query

A reputation API refusing your lookup does not establish that the queried IP is blocked by your destination service. Those are separate requests to separate systems.

For a diagnostic interface, an unavailable score should stay unavailable. Filling the gap with zero turns a collection failure into a reassuring result that was never measured.

2. Make sure you compared the same exit

The proxy hostname and port identify an entry point, not necessarily a fixed exit IP.

Record the observed exit alongside each test. If you use a rotating service, use its documented sticky-session feature when available. Even then, an IP check immediately before or after a request is supporting evidence, not proof that every intervening request used that address.

Also distinguish these two paths:

A server sends a request through a proxy you entered into a form.
Your browser sends a request using its own network configuration.

Do not assume the browser's DNS or WebRTC observations describe the server-side proxy test. A browser extension, split-routing rule or different proxy setting may produce a different path.

3. Read the flags before comparing the numbers

Reputation providers do not all measure the same thing. AbuseIPDB describes its confidence rating in terms of user reports and their age. IP2Proxy's PX12 documentation describes a potential fraud-risk score alongside proxy, usage and threat fields.

References: AbuseIPDB FAQ and IP2Proxy PX12 fields.

In a saved batch of 500 check records, 346 had an IP2Location score of at least 66 while Scamalytics returned zero. Some exits appeared more than once. Without labeled abuse outcomes, this demonstrates disagreement—not which provider was correct.

Do not average the scores or assume every high score is merely proxy detection. Look at the accompanying evidence and your requirement:

Data-center classification: If you purchased residential service, ask the supplier to investigate the classification. If you knowingly purchased a data-center proxy, that label alone is not a product failure.
Abuse reports: Examine recency, categories and supporting detail where available. Neither one report nor a zero score settles whether the address works for your task.
Proxy or VPN flag: Treat it as a classification signal. It is not, by itself, evidence of malicious activity.

4. Reproduce the actual failure

A page returning HTTP 200 is not the same as completing the operation you need.

The same historical batch contained 323 initial YouTube check failures. In matched follow-up records, 90 obtained HTTP 200 and Premium page markers. That narrower result did not verify playback or subscription availability. There was no controlled experiment to establish why the results changed.

Test the specific permitted operation that failed, using your normal account and settings. Record the actual error, not just a checker label. Account status, region, session state and service availability can matter independently of IP reputation.

Change one variable at a time. If the checker fails but the actual operation succeeds, investigate the checker before replacing the proxy. If the real operation repeatedly fails, its error and the service's support guidance are more useful than trying to obtain a lower reputation score.

5. Send a support request someone can act on

Instead of “this IP is bad,” use a short evidence summary. For example, with placeholders rather than real user data:

Expected: the supplied exit should match the purchased residential product.

Observed: provider A repeatedly classifies the same exit as a data center. Provider B returns a low score. Both lookups completed successfully.

Context: timestamps and time zone attached; cache age recorded; exit checked around each attempt.

Actual impact: [operation and exact error, or no observed service failure].

Request: please check the product classification and whether this exit matches the purchased service.

Send identifying addresses only through the supplier's trusted support channel when needed. Remove proxy passwords, API keys, cookies and account tokens from reports. Public discussions rarely need a full IP address to establish the next troubleshooting step.

You do not need every risk card to turn green. You need to know whether a lookup failed, whether a classification conflicts with what you purchased, or whether your actual task is failing. Once those are separate questions, the next step becomes much less expensive to guess.

Disclosure: the author maintains an IP diagnostic tool. The figures are from a non-random historical batch whose saved records were reviewed on September 15, 2026; they are not a provider-accuracy benchmark or a new live test. This article was drafted with AI and checked against those records and the cited documentation. No customer identifiers or credentials are included.