Why a Clean US Residential IP Still Gets Flagged: Font, Timezone, and WebRTC Leaks

1. Why Accounts Still Get Flagged When the Network Looks Clean

Plenty of developers hit this when using AI coding assistants or other overseas AI services from a different region: the node is fast, video plays in 4K, the interface is in English, yet the account is challenged at signup or on first login — sometimes restricted outright. The natural conclusion is “the node was detected, so switch to a clean residential IP.” In practice, several node switches often change nothing.

To understand why, step outside “IP thinking”:

• IPs are easy to fake; the underlying environment is not. The IP is the cheapest field for a risk engine to read and the cheapest for a user to forge. Mature risk systems don’t conclude from IP alone — they put network location, device environment, and account behavior into a single model and cross-check them, where any obvious contradiction adds weight.
• The browser exposes far more than an IP. One ordinary page visit carries dozens of local details: language, timezone, screen, fonts, GPU, audio devices. Together these describe what the device is; the IP only describes where it is.
• Contradictions are more suspicious than oddities. Timezones, languages, and IP geolocation mismatching is common, and no single one of them is anomalous on its own. But a device that claims to be on the US West Coast, renders in English, runs on an East Asian timezone, and reports only Chinese fonts and voices points to an unfinished environment setup.

This article uses “using an AI coding tool across regions” as its worked example, groups the hidden signals in the browser and OS into 15 detection dimensions, and shows how to build a self-check page of your own. The goal is to see the exposure surface first and then optimize deliberately, not to keep rotating nodes.

2. Three Layers of Exposure

Before the individual dimensions, here’s the framework. Risk models see a device environment as three layers:

Layer	What it describes	Typical signals	Hard to fake?
Physical	Where the device is and how it connects	Exit IP and its ownership, latency, carrier type	Low: one node switch changes it
System	What kind of device it is and how it’s used	OS version, region and language settings, timezone, fonts, input methods and voices, hardware specs	Medium: every item must be aligned, and they’re interdependent
Session	Which client is used and how it interacts	Browser engine and version, request headers, TLS fingerprint, automation traces, page behavior	High: changing one part can shift everything

Two points matter:

1. Higher layers are more stable signals. The physical layer can be swapped at will; the system layer often stays unchanged for months; the session layer is bound tightly to the client implementation. So risk engines treat the upper layers as identity anchors — used to link visits across different IPs, different times, and even different accounts.
2. Cross-layer consistency is what gets checked. The engine asks whether the network location actually supports the usage described by the system layer. Examples: the browser language doesn’t match the dominant language of the IP’s region; the local time implies the middle of the night while the account behaves like a continuous weekday workday; the UA says desktop while the logical screen resolution is 360×640.

Below are the 15 dimensions. Each one covers what it exposes, how it’s detected, why it’s risky, and how to fix it.

3. The 15 Core Detection Dimensions

3.1 System Localization Consistency: the Most Overlooked Group

Dimension 1: Font list fingerprinting

• What it exposes: Page JavaScript can enumerate locally installed fonts through CSS and the Canvas text measurement API. If a candidate font and a “baseline font” render the same string with different widths, the system has that font. The usual method tests candidate fonts against serif, sans-serif, and monospace baselines one by one.
• Why it’s risky: Preinstalled OS fonts carry a strong regional signature. Detecting Chinese Hei, Chinese Song, or Kai-style glyphs while the representative fonts of the target region are missing strongly suggests a Chinese-language system. Fonts also appear in “OS + version” combinations — for example, only certain desktop releases ship PingFang-style Chinese glyphs by default. In practice, the font list is close to a fingerprint of “OS plus regional language.”
• How to fix it:
  • ① For cases that genuinely need to run from a Chinese environment, do it in an isolated environment (separate OS user account, VM, or containerized desktop) so the font set matches the target region;
  • ② You can disable rarely used fonts with the OS’s own font management tools, but don’t delete all Chinese fonts. Having no Chinese glyphs at all is itself unusual and counts as over-optimization.

// Font detection idea: if a text rendered with the target font has a different
// width than with the baseline, the font is installed
const canvas = document.createElement('canvas');
const ctx = canvas.getContext('2d');
const probeText = 'mmmmmmmmmmlliMWQ_0123456789';
function isFontInstalled(font, baseline) {
  ctx.font = `72px "${font}", ${baseline}`; // target font first, baseline as fallback
  const withFont = ctx.measureText(probeText).width;
  ctx.font = `72px ${baseline}`;
  return Math.abs(ctx.measureText(probeText).width - withFont) > 0.5;
}
// Three baselines: serif, sans-serif, monospace. Extend the candidate list with
// the common CJK families for each platform as needed.
const candidates = ['KaiTi', 'FangSong', 'SimHei', 'Heiti SC', 'Noto Sans CJK SC'];
for (const family of candidates) {
  if (['serif', 'sans-serif', 'monospace'].some((b) => isFontInstalled(family, b))) {
    console.log('Font detected:', family);
  }
}

Dimension 2: Timezone that doesn’t match the IP’s region

• What it exposes: Intl.DateTimeFormat().resolvedOptions().timeZone returns the IANA timezone name, such as America/Los_Angeles or Asia/Shanghai. The Date object also converts times according to the system timezone.
• Why it’s risky: IP geolocation and browser timezone are the most classic cross-check pair. An exit in Los Angeles with an East Asian timezone means the person and the network are not in the same place. Risk engines also compare timestamps against local daily rhythms to judge whether the behavior fits a real person.
• How to fix it:
  • ① Pick one stable target region long-term and point the IP, the timezone, and the language at it simultaneously;
  • ② Watch for the double-conversion trap: if the target is the US and the user sits in UTC+8, the computed target offset is −480 minutes. If an extra sign is applied during setup, you end up at UTC+8 instead of UTC−8;
  • ③ Many operating systems auto-adjust the timezone from network location, so confirm where the setting comes from to avoid your manual value being overwritten.

Dimension 3: A broken language/region chain

• What it exposes: Language information passes through at least three stages in a single visit:

  • UI language: navigator.language and navigator.languages;
  • Request headers: Accept-Language and its q-weights;
  • Region code: the browser’s locale setting.

  Their value ranges and formats differ, but they should still be logically consistent.

• Why it’s risky: Many people change the UI language and forget the header and the locale. The UI switches to English while the header still prefers Chinese, or the region still reads Chinese (China).
• How to fix it:
  • ① Point the UI language, the request header, and the region setting at the same target region;
  • ② Avoid combinations that don’t occur in reality, such as declaring a single language with no fallbacks;
  • ③ After changing things, reopen the browser and clear site data before verifying, so cached values don’t mislead you.

// Language and region consistency check
const checks = {
  uiLanguage: navigator.language,                       // UI language
  languageList: navigator.languages,                    // ordered by preference
  timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
  // Write the target region as a config like { language: 'en-US', timezones: ['America/Los_Angeles', ...] }
};
console.log(checks); // compare item by item against the expected config; any mismatch is a risk finding

Dimension 4: Regional signals from voices, input methods, and collation

• What it exposes:

  • The language list of the speech recognition engine;
  • The voice list available to speech synthesis (usually organized by language, with a different set per OS);
  • Spell-check languages;
  • The locale that governs text collation.

  Most of these interfaces can be read without permission.

• Why it’s risky: All of this directly reflects the OS’s “language preference.” Even with the browser UI and headers in English, if the voice list is still Chinese-heavy and spell-check uses a Chinese dictionary, “this is a Chinese-language system” still holds.
• How to fix it:
  • ① In the OS language and region settings, make the target-region language the primary one and re-select collation according to regional preference;
  • ② Let speech and spell-check follow the system language rather than adjusting them separately;
  • ③ Input method fingerprints can’t be read directly by a web page, but typing content directly on the machine as a Chinese user reveals obvious Chinese-usage habits. This is a blind spot that network configuration can’t cover.

3.2 Network and Path Consistency: the Second Exit

Dimension 5: The realtime channel leaking your real network address

• What it exposes: Before establishing a connection, the browser’s built-in realtime communication capability (WebRTC) gathers candidate addresses via Interactive Connectivity Establishment (ICE). That includes the local intranet address and the external mapped address discovered through Session Traversal Utilities for NAT (STUN). A page only has to create a connection object and listen for candidate events to get them.
• Why it’s risky: A common misconception is “if the browser goes through the proxy, all traffic goes through the proxy.” In reality, many application-layer proxies only take over certain traffic types, and realtime traffic can bypass them entirely. The result: the IP the page sees belongs to the proxy exit, while a real local network address shows up in the candidates. This kind of “dual exit” is a very clear signal.
• How to fix it:
  • ① In the browser privacy settings, choose “Use only the default public interface” or the equivalent option so other network addresses aren’t exposed;
  • ② At the OS firewall level, block non-proxied processes from connecting directly to the internet, guaranteeing that all traffic uses a single exit;
  • ③ If your proxy tool supports transparent proxying or route-level forwarding, it can take over all traffic including realtime communication.

// Realtime candidate probing: no external server required — host candidates alone reveal local addresses
function probeLocalIps(timeout = 3000) {
  return new Promise((resolve) => {
    const found = new Set();
    let pc;
    try {
      pc = new RTCPeerConnection({ iceServers: [] }); // host candidates appear even without STUN
    } catch (e) {
      resolve([]);
      return;
    }
    pc.createDataChannel('probe'); // trigger ICE gathering
    pc.onicecandidate = (e) => {
      const m = e.candidate?.candidate.match(/([0-9]{1,3}\.){3}[0-9]{1,3}/);
      if (m) found.add(m[0]);
    };
    pc.createOffer().then((o) => pc.setLocalDescription(o));
    setTimeout(() => {
      pc.close();
      resolve([...found]);
    }, timeout);
  });
}
probeLocalIps().then((ips) => console.log('Local candidate addresses:', ips));

Dimension 6: IPv6 and dual-stack bypass

• What it exposes: Modern operating systems enable IPv6 by default. If the network supports IPv6 but the proxy only handles IPv4 traffic, visiting a site that also publishes AAAA records can go out over IPv6 directly.
• Why it’s risky: The site then sees a “mixed view” of an IPv4 proxy address and an IPv6 real address, and a risk engine can associate both with the same session to infer the real network location.
• How to fix it:
  • ① Prefer a proxy exit that supports IPv6 as well, and confirm the target sites are reachable over IPv6;
  • ② If that’s not available yet, disable IPv6 in the proxy tool or at the OS level so there’s no side channel;
  • ③ During self-checks, query both the IPv4 and IPv6 exit addresses from the target network and confirm they belong to the same region — or confirm that IPv6 is unavailable.

Dimension 7: The DNS resolution path exposing your network

• What it exposes: Reaching a domain takes two steps:

  • DNS resolves the domain to an IP address;
  • a connection is established to that IP.

  The two steps can travel over different network paths.

• Why it’s risky: If the connection goes through the proxy but resolution goes through the local recursive resolver, the lookup records stay on servers operated by the carrier at the user’s location. A risk engine able to analyze resolution logs can learn the origin that way. On top of that, when the resolver’s region differs from the proxy exit, some services’ CDN and validation logic can behave differently.
• How to fix it:
  • ① Put DNS resolution and the connection on the same proxy path — typically via the proxy’s built-in DNS feature, or encrypted DNS combined with proxy rules;
  • ② Don’t mix public resolvers from different regions, e.g. an exit in the US with a resolver in another region;
  • ③ When diagnosing, check without relying on cache: compare the addresses a given domain returns from different resolvers.

Dimension 8: IP “cleanliness” and behavioral contradictions

• What it exposes: Even among “residential IPs,” trustworthiness varies enormously. Risk engines typically weigh more than the label:
  • the operator type that owns the range;
  • whether it comes from a datacenter range;
  • how heavily the range is shared or recycled;
  • whether there’s a history of anomalous behavior.
• Why it’s risky: A common situation is many unrelated users hitting the same service from the same exit at the same time — that IP is then naturally treated as high risk. Physical contradictions can also feed the judgment, such as latency that doesn’t match the target region, or an exit carrier with no real network presence in that region.
• How to fix it:
  • ① A self-check page can’t query IP reputation directly. Cross-check through IP geolocation lookups, threat-intelligence services, or public detection endpoints from risk vendors, and compare against official query results;
  • ② Prefer a dedicated exit or a network type with a low reuse rate, and avoid switching nodes frequently;
  • ③ Keep the exit stable per account and per region. Rapidly changing exit countries in a short window carries more risk than a single node being recognized.

3.3 Client and Protocol Stack Consistency: Keep the Coat Matching the Body

Dimension 9: UA spoofing that contradicts the engine and platform claims

• What it exposes: The UA string declares browser type, version, and operating system, but it’s a field the client can rewrite freely. Risk engines compare it against:
  • User-Agent Client Hints, which provide structured fields for platform, platform version, engine brand and version, architecture, and device model;
  • navigator.platform;
  • hardware concurrency and device memory.
• Why it’s risky: Typical contradictions: the UA claims a mobile OS while screen size and pointer interaction characteristics say desktop; the UA claims desktop while Client Hints report a mobile platform.
• How to fix it:
  • ① The safest approach is not to rewrite the UA at all — use the browser that ships with your system;
  • ② If you must, change the UA, the Client Hints, and the platform declaration together, and keep them consistent with hardware signals like screen and pointer capabilities;
  • ③ After changes, re-verify on a public detection site to make sure no field was missed.

Dimension 10: A transport fingerprint that doesn’t match the client’s claims

• What it exposes: When a browser opens an encrypted connection, its first packet (ClientHello) contains:

  • supported cipher suites and their order;
  • the extension list;
  • elliptic curve parameters;
  • supported protocol versions.

  Hashing these yields what’s commonly called the TLS fingerprint (the JA3 and JA4 families). The HTTP/2 settings frame and header ordering at the application layer are distinguishing too.

• Why it’s risky: Different browser engines and versions produce different TLS stacks, so the TLS fingerprint can identify a client outside of JavaScript. If an intercepted or rewritten UA claims a mainstream browser while the TLS fingerprint clearly comes from the default library of some scripting language or automation framework, the two contradict each other directly. This is worth noting for developers who favor CLI-based AI coding tools: the network requests behind those tools are issued by the runtime, so their TLS fingerprint is naturally different from a real browser’s.
• How to fix it:
  • ① Do authentication, subscription, and sensitive operations in a real browser rather than requesting APIs directly from a script or CLI tool;
  • ② When programmatic access is genuinely required, use the officially provided APIs and credentials;
  • ③ Don’t hand-craft header ordering; some HTTP client libraries can be configured to mimic browser defaults.

Dimension 11: Automation and headless browser traces

• What it exposes: Automation frameworks and headless mode leave features that are hard to fully erase:
  • the browser automation flag property set to true;
  • anomalous object contents in headless mode, such as an empty language list or a missing plugin list;
  • driver scripts injecting variables into the page or rewriting native functions;
  • a fixed viewport size and no real mouse movement or scroll traces.
• Why it’s risky: Automation traces are a separate signal line from “real human interaction.” Even with a perfectly consistent network and system layer, automation raises the account’s overall risk level. Some browser vendors even probe for headless environments in-page specifically to block automated access.
• How to fix it:
  • ① Do critical operations — signup, login, adding a payment method — manually in a real browser;
  • ② Limit automation scripts to non-sensitive, authorized tasks and control their frequency;
  • ③ For batch work, prefer official APIs and credentials over driving a browser.

3.4 Hardware, Graphics, and Audio Fingerprints: Identity You Can’t Swap Temporarily

Dimension 12: Canvas and WebGL rendering fingerprints

• What it exposes:
  • Canvas draws the same text or shape into a canvas and then exports pixel data or a hash. Different devices, GPU drivers, and system font rendering settings produce subtle differences.
  • WebGL exposes the GPU vendor and renderer strings, the list of supported extensions, and many rendering parameters.
• Why it’s risky: The GPU model is a typical “device model” signal. For example, a renderer string naming a GPU optimized for Apple computers, while the UA and fonts both point to a desktop PC, is a contradiction in itself. Canvas and WebGL fingerprints are also highly stable, making them a common basis for cross-account linking.
• How to fix it:
  • ① Avoid logging into multiple accounts from the same device and browser configuration. Even if a risk engine can’t confirm immediately, it will group them into the same “device cluster”;
  • ② For multi-account scenarios, give each account its own device environment — VM, separate OS user account, containerized desktop;
  • ③ Built-in browser fingerprint protection adds noise, but it isn’t absolute anonymity. The relationships between the remaining signals still need to stay plausible.

Dimension 13: Audio processing fingerprints and device names

• What it exposes:
  • Audio fingerprint: an offline audio context processes a fixed waveform, and differences in the underlying audio algorithm implementation produce extremely small deviations in floating-point results.
  • Device names: the media device enumeration interface returns the audio input and output device names, which often contain the sound card chip and vendor names. Without microphone authorization you only see device kinds and counts; with it, you see specific names.
• Why it’s risky: The audio fingerprint is as stable as Canvas and WebGL. Leftover Chinese vendor identifiers in device names can also reveal the device’s sales region.
• How to fix it:
  • ① Don’t grant microphone or camera permission unless necessary — it reduces exposure of concrete device names;
  • ② As with Canvas and WebGL, isolate device environments per account;
  • ③ Replacing hardware like a sound card or GPU changes the related fingerprints, so avoid changing devices frequently.

Dimension 14: Hardware specs and screen parameters

• What it exposes:
  • Hardware concurrency (approximate logical core count) and device memory (privacy-protected, returning buckets like 2, 4, 8);
  • screen resolution, available area, and color depth;
  • device pixel ratio (physical pixels over CSS pixels);
  • touch points and pointer precision;
  • the battery status interface, still present in some browsers.
• Why it’s risky: Together these form a “device profile.” Any single parameter may collide with someone else’s, but the combination is quite distinguishing. Typical contradictions:
  • a desktop UA with a phone resolution;
  • a device pixel ratio that doesn’t fit the resolution;
  • a claim of desktop while reporting five touch points;
  • a near-1 device pixel ratio on a high-resolution screen.
• How to fix it:
  • ① Don’t use the browser devtools “device emulation” mode to visit pages that require authentication — the parameter combinations it produces are often self-contradictory;
  • ② Keep the OS’s default scaling to avoid creating rare parameter combinations;
  • ③ Treat the parameters above as ground truth from the real device and don’t deliberately alter them.

Dimension 15: Permissions, privacy toggles, and residual data

• What it exposes:
  • Permission query interfaces: querying geolocation, notification, and camera permission state without triggering a prompt, with results like “granted,” “denied,” or “prompt”;
  • privacy and security toggles: Global Privacy Control, Do Not Track, third-party cookie policy, tracking protection, and so on;
  • residual state: cookies, local storage, cache, service worker registrations.
• Why it’s risky:
  • Most users deny geolocation by default, so “denied” is unremarkable. But when several accounts on the same environment all sit at “granted” long-term, that’s continuous location reporting — and the reported location can contradict the IP’s region.
  • A shared browser profile lets multiple accounts use the same local storage, and a risk engine can link them client-side.
• How to fix it:
  • ① Don’t grant geolocation unless genuinely needed;
  • ② Give each account a separate browser profile directory and run it as a separate OS user to avoid profile mixing;
  • ③ An outdated browser version is also an exposure. Keep it on a supported version alongside OS updates.

4. From Findings to a Risk Score

Detecting a problem and knowing how dangerous it is are two different things. A single anomaly rarely triggers a block; what matters is the stacking of several. A practical approach is to turn findings into an explainable score.

// Example rules: weight is the risk weight, reason is the explainable conclusion
const RULES = [
  { id: 'tz-ip-mismatch',   weight: 30, test: (f) => !f.timezone.startsWith(f.ipRegionPrefix),
    reason: 'Timezone does not match the continent of the IP' },
  { id: 'lang-region-mismatch', weight: 20, test: (f) => !f.languages.some((l) => l.startsWith(f.ipLangPrefix)),
    reason: 'UI language does not match the dominant language of the IP region' },
  { id: 'webrtc-leak',      weight: 25, test: (f) => f.localIps.length > 0,
    reason: 'The realtime channel exposed local network addresses' },
  { id: 'headless',         weight: 40, test: (f) => f.automationFlags > 0,
    reason: 'Automation or headless browser traces present' },
  // Add the remaining rules the same way, one per dimension
];
function assess(f) {
  const findings = RULES.filter((r) => r.test(f)).map((r) => ({ id: r.id, weight: r.weight, reason: r.reason }));
  const score = Math.min(100, findings.reduce((sum, r) => sum + r.weight, 0)); // capped at 100
  let level = 'low risk';
  if (score >= 60) level = 'high risk';
  else if (score >= 30) level = 'medium risk';
  return { score, level, findings };
}

Three principles for designing the scoring model:

1. Weight should track risk. When “automation traces + high-risk exit + localization contradictions” appear together, the environment is neither a real person’s device nor a device in the target region, and should be judged high risk overall.
2. Fix the identity anchors first. Timezone, language, and fonts say “who and where” — fixing them yields the largest reduction in overall risk.
3. Value cross-dimension combination rules. “English UI + Chinese voice list” is unremarkable in isolation but worth flagging together. Such combination rules often discriminate better than any single high-weight item.

5. Building Your Own Environment Health-Check Page

With the dimensions and the scoring method in hand, you can build a self-check page of your own. Here’s a directly implementable approach.

5.1 Design principles: client-side only, local, explainable

1. Process locally, don’t upload raw data. All detection runs inside the browser and the report is generated locally. If centralized aggregation is genuinely needed, report only boolean conclusions and risk levels, and tell users clearly.
2. Anonymous report in one click. Redact sensitive fields such as concrete addresses and device identifiers, keeping only conclusions and remediation advice so the report is easy to share or archive for comparison.
3. Explainable conclusions. Each finding must state which signal mismatched which expectation, not just a number.

5.2 Result model and collection entry points

// Standard shape of a single check result
const item = (id, title, value, expected, status, advice) =>
  ({ id, title, value, expected, status, advice }); // status: 'pass' | 'warn' | 'fail'
// Collection entry points: all native browser APIs, no third-party dependencies
const collectors = {
  timezone: () => Intl.DateTimeFormat().resolvedOptions().timeZone,
  languages: () => navigator.languages,
  platform: () => navigator.userAgentData?.platform ?? navigator.platform,
  localIps: probeLocalIps,
  hardwareConcurrency: () => navigator.hardwareConcurrency,
  deviceMemory: () => navigator.deviceMemory,
  screen: () => ({
    size: `${screen.width}x${screen.height}`,
    dpr: window.devicePixelRatio,
    touchPoints: navigator.maxTouchPoints,
  }),
};
async function runChecks() {
  const results = [];
  for (const [id, fn] of Object.entries(collectors)) {
    try {
      results.push(item(id, id, await fn(), null, 'warn', 'Needs manual review'));
    } catch (e) {
      results.push(item(id, id, 'collection failed', null, 'warn', 'Some browsers may restrict this API'));
    }
  }
  return results;
}

5.3 Consistency checks and result display

On top of the collected values, add an “expected configuration” (target region, target language, and so on), compare item by item, and display per-dimension results as cards, tables, or a radar chart. Put an actionable fix next to every finding.

// Consistency check example: if the client offset differs from the expected IP-region
// offset by more than 3 hours, mark it inconsistent
function checkTimezoneByOffset(clientOffsetMin, expectedOffsetMin) {
  const diffHours = Math.abs(clientOffsetMin - expectedOffsetMin) / 60;
  return item('tz-offset', 'Timezone offset', `${clientOffsetMin} minutes`, `${expectedOffsetMin} minutes`,
    diffHours > 3 ? 'fail' : 'pass',
    diffHours > 3 ? 'System timezone differs significantly from the target region; adjust it in the OS' : '');
}

5.4 Deployment

The self-check page is a purely static site, so you can host it on any object storage service’s static website hosting feature and serve it through a CDN. No server to maintain, which makes it a good fit for an internal team tool.

6. Optimization Checklist: From Naked to Consistent

Dimension	How it’s detected	Core risk	Direction
1. Font list	CSS / Canvas text measurement	CJK glyphs expose system language and version	Isolated environment; don’t empty out CJK fonts
2. Timezone	Intl / Date API	Contradicts IP geolocation	Align with the target region; watch the sign
3. Language and region	navigator.languages / Accept-Language	Only the UI changed, header missed	Unify UI, header, and region
4. Voices and spell-check	Speech recognition and synthesis APIs, spell-check language	System language preference leaks through	Set the target-region language as primary
5. Realtime channel	RTCPeerConnection candidate gathering	Exposes local network addresses	Restrict the channel; route-level forwarding
6. IPv6 dual stack	Dual-stack exit address lookup	IPv6 side channel goes direct	Unify the exit or disable IPv6
7. DNS path	Resolver comparison	Lookups reveal origin	Same path for resolution and connection
8. IP cleanliness	Geolocation, threat intel, reputation APIs	Exit is reused or has a bad history	Dedicated exit; stable, infrequent switching
9. UA and engine claims	UA, Client Hints, platform property	Declaration contradicts the real client	Don’t rewrite the UA; if you do, sync the whole chain
10. Transport fingerprint	TLS fingerprint, HTTP/2 fingerprint	CLI or script requests expose the client	Sensitive operations in a real browser
11. Automation traces	Flag properties, native object integrity	Not real human interaction	Do key operations manually
12. Canvas / WebGL	Canvas hash, GPU and extension parameters	Stable fingerprints link accounts	Isolate device environments per account
13. Audio and device names	Offline audio processing, device enumeration	Audio fingerprint; regional markers in device names	Don’t grant mic access without need
14. Hardware and screen	Hardware and screen parameter APIs	Self-contradicting parameter combinations	Real device; no device emulation
15. Permissions and residual data	Permission queries, privacy toggles, storage	Location contradictions, linked accounts	Separate browser profile and OS user

Ordered by return on effort, a three-step approach works best:

1. Align the physical and system layers first (items 1–8). This is where the payoff is highest and the cost lowest: timezone, language, DNS, and network exit. In most “I changed several IPs and still got blocked” cases, the root cause sits in this layer.
2. Then check session-layer contradictions (items 9–11). The focus is avoiding a mismatch between the “browser shell” and the implementation underneath. Keep doing sensitive operations manually in a real browser.
3. Finally, isolate at the device level (items 12–15). Multi-account users need a separate device environment per account. This is the most expensive step and the one most often skipped.

After optimizing, re-run the self-check and archive the before-and-after reports for comparison. The trend across dimensions in the report tells you more than a single score.

7. Scope and Compliance

1. The self-check tool is for diagnosis only. The detection ideas here are meant to help developers understand their machine’s information exposure and protect their own privacy. They should not be used to evade a platform’s normal security mechanisms.
2. Respect platform rules and local law. When accessing online services from another region, follow the target service’s terms of use and access terms as well as applicable local law. Account restrictions or data loss resulting from evading risk controls are the user’s responsibility.
3. Rely on official channels. For subscriptions, authentication, and API calls, use the platform’s official documentation and APIs. Network and environment adjustments should also comply with the requirements of the network you’re on.

Conclusion

“I changed my IP and still got blocked” usually has nothing to do with the IP itself — the device environment never formed a coherent whole. The IP answers where you come from. Timezone, language, fonts, voices, network exit, and the transport fingerprint together answer who you are and how you work. Once the two disagree, even the cleanest IP is just a hole in an invisibility cloak.

Rather than trial-and-error across nodes, run one systematic environment health check: see the exposure surface, quantify the risk, then fix it in priority order. The same methodology applies to everyday privacy self-checks and to building endpoint security baselines inside a company.