Clean Proxy IP Is Not Enough: Audit Fonts, Time Zones, WebRTC, DNS, and TLS Fingerprints

    A clean proxy IP only answers where requests come from; it does not prove that the surrounding environment is consistent. This article breaks down 15 environment signals, including fonts, Canvas/WebGL rendering, screen geometry, UA-CH, time zone, hardware, WebRTC ICE candidates, DNS, IPv6, TLS, HTTP/2/QUIC, session state, and proxy headers, then explains how risk models cross-check them. It includes browser and CLI self-checks, a priority-based remediation checklist, and a cloud-scale detection architecture.

    Clean Proxy IP Is Not Enough: Audit Fonts, Time Zones, WebRTC, DNS, and TLS Fingerprints

    1. Introduction: A Good IP Does Not Mean a Clean Environment

    Many developers encounter this situation when configuring an overseas network egress for AI coding tools: a premium “native” IP scores well on IP cleanliness checks, streaming platforms work normally, and the system language is set to English. Yet shortly after topping up an account or initializing a workspace, the service asks for re-verification or disables the account.

    The problem is usually not the proxy node itself. It is the gap between what the IP says and what the rest of the environment says. The egress IP answers only the first question asked by a risk-control system: “Where did the request come from?”

    Several harder questions follow:

    • What device model, operating system, and time zone is being used?
    • How large is the screen, and what is its resolution?
    • Which GPU and driver version are used to render the page?
    • If UDP hole punching is used, where does the real public address appear?
    • Which domains does the browser contact for each request?
    • Does the TLS handshake style match the claimed browser version?

    Risk-scoring models cross-check these signals. For example, system fonts may show a clear Chinese-language environment, the time zone may remain in East Asia, the hardware may look like a common office laptop, while the egress IP is located in North America. Any one of these signals may look harmless. Together, they form an obvious contradiction.

    Therefore, checking “one IP” is not enough. You need to audit the entire runtime environment using an engineering approach: which signals can be read, whether they are mutually consistent, how risks should be ranked, and how to fix and regression-test them.

    The following sections group the checks into five categories and 15 items for systematic self-verification.

    2. Signal Map: 15 Environment Fingerprints

    2.1 Presentation Layer: System and Browser Primitives

    ① System-preinstalled fonts.
    Modern web pages can enumerate local fonts using measurement fallback methods with CSS and Canvas measureText. A full set of Chinese serif fonts, Chinese sans-serif fonts, and multiple default fonts from Chinese font vendors is a very typical combination for Chinese operating systems.

    ② Canvas rendering.
    Drawing text or shapes on a Canvas and then reading pixels can reveal subtle differences between operating systems: font rasterization engines, anti-aliasing algorithms, and subpixel rendering may all differ. Under combinations of letter spacing, gradients, and clipping, the same drawing code can often distinguish the Windows and macOS builds of the same browser.

    ③ WebGL hardware.
    Using getParameter together with debug extensions, a page can read the GPU vendor, graphics card model, driver version, renderer string, maximum texture size, anisotropic filtering level, extension list, and other parameters. If many accounts show exactly the same GPU model and driver version, this may mean that virtual machines were cloned from a template, or that a fingerprint browser did not randomize these values properly.

    ④ Screen and viewport.
    screen.width/height reflects the logical screen resolution. availWidth/availHeight further subtracts the height of system taskbars and menu bars. devicePixelRatio reflects scaling. window.outerWidth reflects window size. Combined, these values can help infer the operating system, whether an external monitor is connected, whether the window is maximized, and whether the claimed device type in the user agent is plausible.

    ⑤ UA and UA-CH.
    A User-Agent string can be edited manually. However, high-entropy values in UA-CH, such as platform version, system architecture, and the full version list, are generated by the browser from the real system and are difficult to change with ordinary scripts. If the UA claims a new browser version while the system version reported by UA-CH is outdated, that mismatch is suspicious.

    ⑥ Time zone and regional formats.
    Intl.DateTimeFormat().resolvedOptions().timeZone, Date().getTimezoneOffset(), and default date, number, and currency formats are determined by operating system settings. They may also be affected by browser options such as “automatically match time zone based on IP.” A mismatch between the time zone and the geographic location of the egress IP is one of the easiest contradictions to detect.

    ⑦ Hardware and runtime environment.
    navigator.hardwareConcurrency, navigator.deviceMemory (quantized by tier), navigator.maxTouchPoints, the battery interface, CPU architecture, operating system version, and WebAssembly-related features can all contribute to environment identification. A long-term “virtual machine feel” increases the concentration of devices during device clustering.

    2.2 Network Layer: Where Requests Actually Leave

    ⑧ WebRTC ICE candidate addresses.
    To establish connections behind NAT, WebRTC uses STUN servers to discover public addresses (srflx candidates), collects local interface addresses (host candidates), and may also use relay addresses (relay candidates). If a proxy only forwards TCP or application-layer traffic, UDP probes may go directly through the local network, exposing the real public IP. For privacy reasons, some browsers replace host candidates with randomly generated .local hostnames, which is normal.

    ⑨ DNS resolution path.
    Whether DNS requests are sent by the local resolver or forwarded through a remote proxy determines two issues: whether the list of accessed domains is exposed to the local network, and whether the DNS egress matches the HTTP egress. CDN nodes returned by local DNS are often geographically “closer.” If the DNS resolution result for the website account region clearly differs from the claimed country, that is also a mismatch signal.

    ⑩ IPv6 and dual-stack.
    Many proxies only handle IPv4. If IPv6 is enabled on the local machine, the browser may bypass the proxy and connect directly to IPv6 targets, exposing the real address. In addition, if one website receives requests from both your IPv4 proxy and your IPv6 home connection, correlating those requests can be obvious.

    ⑪ Outbound domain visibility.
    Targets observed from the network egress, including DNS, SNI, and QUIC connections, can reveal which services the tool actually accessed. This includes login endpoints, telemetry reporting, update checks, and other traffic.

    2.3 Transport Layer: The Handshake Has a Recognizable Style

    ⑫ TLS fingerprint.
    The ClientHello fields in TLS include the TLS version, cipher suite order, extension list and order, supported elliptic curves, and other parameters. Different engines differ significantly in these fields, and they are often hashed into fingerprints. If a program uses a generic HTTP library, such as Python requests or Node.js fetch, but disguises itself as a browser UA, a fingerprint mismatch is inevitable. As a historical note, the “Gecko” token commonly seen in UAs originated from early browsers pretending to be another browser for compatibility, and it no longer has real identifying value.

    ⑬ HTTP/2 and QUIC features.
    HTTP/2 SETTINGS frame parameter values and order, the initial WINDOW_UPDATE size, pseudo-header order, and even header field order can vary by client. QUIC connections over UDP 443 may also expose TLS handshake fingerprints and initial congestion window characteristics.

    2.4 Session Layer: Identity and Behavior

    ⑭ Session correlation and behavior patterns.
    Cookies, localStorage/IndexedDB, Service Worker registrations, reused working directories and configuration files on the same machine, operation rhythm, preferred language, and task type similarity can all be included in account correlation and clustering analysis. If virtual machines cloned from the same batch first become active within the same time window, clustering them together is almost inevitable.

    ⑮ Software stack and proxy features.
    Local HTTP proxies, transparent proxies, and system-level VPNs may rewrite, add, or remove request headers. Automation tools may carry the webdriver marker or lack expected objects such as navigator.plugins or Chrome brands. In addition, forwarding traces such as X-Forwarded-For and Via in request headers can expose the intermediate chain.

    3. Core Logic: Risk Control Does Not Judge One Feature in Isolation

    After understanding the individual signals, the more important question is how these signals are used. Mature risk-control logic usually has three layers:

    1. Normalization. IP location, time zone, language, fonts, operating system version, and other values are mapped into the same geographic and environmental coordinate system.
    2. Consistency checking. These coordinates are compared item by item to see whether they are self-consistent.
    3. Cluster correlation. The similarity among accounts, devices, and networks is calculated. Similar entities are grouped into a cluster, and high-risk individuals are treated together with other members of the cluster.
    Expected Profile Conditions That Must Be Satisfied Together Common Contradictions
    Ordinary office endpoint IP region, time zone, language, system region, and font set match each other IP in North America, time zone in East Asia, fonts dominated by Chinese fonts
    Developer workstation System version matches UA-CH, driver matches GPU model, runtime environment is stable UA claims a new system version, but UA-CH reports an older system version
    Single network path DNS egress, HTTP egress, and UDP egress are geographically consistent STUN probes expose the real public IP; DNS is resolved locally

    4. Self-Check Practice: Verify Signals in the Browser and on the Command Line

    4.1 Font Detection

    1. // Principle: compare the rendered width of “target font + generic fallback family”
    2. // with the width of the generic fallback family alone.
    3. function detectFonts(fonts, baseFamilies = ['monospace', 'sans-serif', 'serif']) {
    4. const canvas = document.createElement('canvas');
    5. const ctx = canvas.getContext('2d');
    6. const test = 'mmmmmmmmmmlli';
    7. const widthOf = (family) => { ctx.font = `72px ${family}`; return ctx.measureText(test).width; };
    8. return fonts.filter(f =>
    9. baseFamilies.some(base => widthOf(`'${f}',${base}`) !== widthOf(base))
    10. );
    11. }
    12. // Replace the candidate font list with fonts actually installed on the target system.
    13. console.log(detectFonts(['<FONT_A>', '<FONT_B>', '<FONT_C>']));

    The principle is that if the target font does not exist, the browser falls back to the specified generic font family and the width does not change. If the font exists, the glyph metrics differ and the width changes. For better accuracy, DOM element offsetWidth measurements can also be used.

    4.2 WebRTC Egress Verification

    1. async function collectIce() {
    2. const out = { host: [], srflx: [], relay: [] };
    3. // Fill in the STUN/TURN service addresses you actually use.
    4. const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:<YOUR_STUN_SERVER>' }] });
    5. pc.createDataChannel('');
    6. pc.onicecandidate = e => {
    7. if (!e.candidate) return;
    8. const [, , , addr, , , type] = e.candidate.candidate.split(' ');
    9. if (type) out[type].push(addr);
    10. };
    11. await pc.setLocalDescription(await pc.createOffer());
    12. await new Promise(r => setTimeout(r, 3000)); // Wait for candidate collection to finish.
    13. pc.close();
    14. // If srflx does not belong to your expected region, UDP traffic may not be going through the proxy.
    15. return out;
    16. }

    4.3 Multi-Signal Consistency Report

    1. (async () => {
    2. const tz = Intl.DateTimeFormat().resolvedOptions().timeZone;
    3. const uaData = navigator.userAgentData
    4. ? await navigator.userAgentData.getHighEntropyValues(['platformVersion', 'architecture'])
    5. : null;
    6. const gl = document.createElement('canvas').getContext('webgl');
    7. const dbg = gl && gl.getExtension('WEBGL_debug_renderer_info');
    8. console.table({
    9. timezone: tz,
    10. offsetMinutes: new Date().getTimezoneOffset(),
    11. languages: navigator.languages.join(','),
    12. cores: navigator.hardwareConcurrency,
    13. screen: `${screen.width}x${screen.height}@${devicePixelRatio}x`,
    14. platformVersion: uaData?.platformVersion,
    15. gpu: dbg ? gl.getParameter(dbg.UNMASKED_RENDERER_WEBGL) : 'n/a',
    16. ice: await collectIce(),
    17. });
    18. })();

    4.4 Quick Command-Line Checks

    1. echo "TZ=$TZ LANG=$LANG LC_ALL=$LC_ALL" # Time zone and language of the container/terminal
    2. cat /etc/timezone 2>/dev/null || timedatectl # System time zone
    3. env | grep -i proxy # Proxy-related environment variables
    4. curl -s https://ifconfig.co/json | head -20 # HTTP egress address and attribution
    5. dig +short whoami.akamai.net @ns1-1.akamaitech.net 2>/dev/null # Recursive DNS egress actually used (optional)

    5. Remediation Checklist: Priority-Based Governance

    P0: Network Egress Consistency (Highest Priority)

    • Take over UDP globally. Enable a proxy mode that supports UDP forwarding so that STUN, QUIC, and WebRTC UDP traffic leaves through the desired egress.
    • Avoid dual-stack bypass. For address families not covered by the proxy, block direct access at the system level.
    • Unify DNS. Disable direct use of local DNS. Use encrypted DNS through the same proxy path. Avoid EDNS Client Subnet leaking local geographic information.
    • Block direct connections. At the system firewall level, prevent applications from bypassing the proxy and connecting directly.

    Example configuration in a common proxy-client format:

    1. dns:
    2. enable: true
    3. enhanced-mode: fake-ip # Resolve domains remotely through the proxy so DNS egress matches HTTP egress.
    4. fake-ip-filter: ['*.local', 'localhost.ptlogin2.example.com', '+.example.com']
    5. fallback: ['https://1.1.1.1/dns-query', 'https://8.8.8.8/dns-query'] # Replace with your encrypted DNS endpoints.
    6. rules:
    7. - IP-CIDR,127.0.0.0/8,DIRECT
    8. - GEOIP,PRIVATE,DIRECT
    9. - MATCH,PROXY # All other traffic goes through the proxy, including UDP if the node supports UDP forwarding.

    System-level fallbacks are still required: the firewall should prevent applications from accessing the public internet directly, and IPv6 should be disabled or routed through the proxy as well.

    P1: Environment Consistency

    • Align time zone and region. Set the corresponding TZ environment variable and time zone data on terminals and containers. In browsers, enable “automatically match time zone based on IP,” or set the time zone manually according to the egress.
    • Align language and regional formats. Set locale environment variables such as LANG and LC_ALL on terminals. Synchronize browser preferred language and regional formats with the egress location.
    • Trim font sets. Keep only common fonts for the target system. Avoid installing many multilingual font packs.
    • Use dedicated workspaces. Each instance should use an independent container or virtual machine to isolate configuration files, caches, and login state, avoiding multiple accounts on one machine.
    • Match versions. Keep the UA, UA-CH, and HTTP client fingerprint consistent with the real runtime. When calling APIs programmatically, use the fingerprint of the HTTP client itself instead of forging a browser UA.

    P2: Reduce Clustering

    Virtual machines and containers are suitable for building a consistency baseline, but template cloning creates high homogeneity. Therefore, after an instance is created, differentiated initialization is still needed:

    • Generate independent machine identifiers and hostnames. Use independent system volumes and configuration files.
    • Create instances at different times to avoid launching them all at once.
    • Use newer system images and runtime versions.

    Fingerprint randomization and browser-level protection plugins can increase feature entropy, but they also have side effects. Forged WebGL parameters may contradict real driver behavior, and random Canvas noise may interfere with normal page rendering. The goal should be self-consistency, not blind randomization.

    Regression Verification

    After each adjustment, collect the same set of metrics again, save snapshots, and compare whether key items fall within the target range.

    Check Item Expected Result Fails If
    HTTP egress Matches the target region Shows the real attribution
    srflx candidate Matches the target region Shows the real public IP or a local private address
    DNS egress Matches the target region Is geographically inconsistent with the target
    Time zone and language Match the target Still point to the original region
    UA-CH platform version Matches the real system Shows a mixed or contradictory version
    TLS fingerprint Matches the actual client The claimed UA contradicts the underlying fingerprint

    6. Large-Scale Detection: Build a Fingerprint Detection Service in the Cloud

    Local scripts are suitable for individual self-checks. Teams need a detection service that covers more users and continuously tracks changes.

    A pure front-end solution has natural advantages: signals such as fonts, Canvas, WebGL, UA-CH, and time zone can only be collected in the user’s browser, and sensitive operations do not need to leave the local environment. Detection results can be returned as hashes or scores, which helps protect privacy and avoids exposing the full fingerprint.

    On cloud platforms such as Baidu AI Cloud, such a pipeline can be assembled from common cloud services:

    1. Access layer. Object storage hosts the front-end page, and a CDN distributes it from nearby locations.
    2. Execution layer. The browser calculates hashes of the font list, Canvas and WebGL values, consistency scores, and remediation suggestions. Only scores and risk labels are returned.
    3. Data layer. Function compute performs data cleaning and aggregation. A message queue absorbs peak traffic. Log services provide centralized storage and retrieval.
    4. Alerting layer. Monitoring and alerting set thresholds for metrics such as “real IP leakage rate” and “time zone mismatch rate,” and notify relevant staff when anomalies occur.

    Additional engineering considerations:

    • Front-end code is publicly readable. Detection logic may be referenced or bypassed directly, so key decisions should be cross-checked on the server side.
    • Containerized browsers and new headless browsers may actively flatten some fingerprints, such as navigator.webdriver or missing plugin lists. Detection rules should distinguish “privacy protection” from “abnormal environment.”
    • Every metric should include a confidence score. A single signal should not be treated as a final conclusion.

    7. Boundaries and Compliance: Technical Capability Is Not Authorization

    This article focuses on environment detection and consistency governance. Several boundaries need to be clarified:

    • Terms of service. Using the methods in this article to bypass identity verification or evade risk controls may violate relevant service terms and may create account or data risks.
    • Privacy minimization. Collecting device and browser fingerprints may involve personal information and cross-border data transfer. Notice-and-consent and minimum-necessary principles should be followed. Prefer local computation and upload only aggregated results.
    • Enterprise environments. Development teams should be provided with legal, compliant, and stable ways to access tools, such as centralized deployment and management of cloud resources, rather than relying on personally built proxies.

    8. Conclusion: From Guesswork to Measurable Engineering

    The awkward situation of “thinking you are in California while the device information says otherwise” comes from treating security as a single metric. IP cleanliness is only the entrance. Fonts, time zone, Canvas and WebGL rendering, WebRTC and DNS egress, TLS handshake fingerprints, and other signals together form the device’s digital profile.

    A practical approach is to treat these signals as a set of observable, verifiable, and regression-testable system metrics:

    1. First, list all signals that can be read.
    2. Then check each signal against consistency principles.
    3. After that, fix issues in the order of P0 to P2.
    4. Finally, verify the effect through snapshot comparison.

    After completing this process, troubleshooting changes from “guesswork” to an engineering practice that is measurable and reproducible, whether the goal is account security or governance of your own risk-control and privacy issues.