Google Search CAPTCHA Diagnostics: Reading a 10-Proxy Test

Start with the experiment that actually ran

A search that works through one proxy and stops at a challenge through another creates an awkward debugging question: did the browser change, did the network change, or did the observation miss an intermediate state? A small comparison is useful because it gives that question a concrete set of outcomes.

In a September 16, 2026 experiment, 如意 of 如意私塾 searched for claude through ten proxy exits using ruyipage and a customized Firefox build reported as version 155. Five runs reached normal results; five reached a blocked state. The author stopped at the challenge boundary without interacting with the CAPTCHA. This article examines the published report; SpideyData has not independently rerun the experiment.

The source describes direct browser searches. Its title includes serpapi, but the reported procedure does not benchmark the SerpApi service. Keeping the tested system explicit prevents a browser observation from becoming an unsupported comparison between API providers.

The ten reported outcomes

The following rows retain the source's order, public exit addresses, outcomes, and reported result counts. They describe one historical sample. The addresses are evidence from that sample, rather than a current recommendation for any exit, provider, or region.

Five of ten runs returned results, for an observed proportion of 50%. The reported counts were eight or ten on those runs and zero on the blocked runs. These are counts produced by the author's result detector, not a measure of all results available for the query.

A constant recipe can produce different browser states

The author kept the fingerprint-generation procedure consistent while changing proxy nodes. That is a useful starting point, but it does not mean that IP was the only changing value. The procedure derived locale, time zone, and geolocation from the exit; it also selected hardware profiles and generated new Canvas and Audio seeds. Each run used a fresh browser profile.

Those choices make the result a comparison of complete route-and-profile combinations. They do not isolate the causal effect of a single IP address. To diagnose a mismatch, retain both the recipe version and the values it actually produced. A label such as same fingerprint logic is too coarse to reconstruct a browser session.

• Record the browser binary and major version, profile identifier, viewport, locale, time zone, geolocation, and observed request headers for each run.
• Record the selected proxy node and separately measure the exit seen through the path the browser will use.
• Distinguish a fresh profile from a returning session; their storage and consent histories are different experimental conditions.
• Record time and run order. A sequential test also changes when each request reaches the service.

Verify the route before interpreting the page

The source's local mihomo setup exposed a Windows named-pipe controller while its TCP controller was disabled. Its proxy listener and its controller were separate endpoints. A failed request to the usual localhost controller port would therefore diagnose the wrong transport, rather than establish that the proxy was unusable. mihomo documents named-pipe control separately from TCP control.

A node-selection response is only one checkpoint. The source read the selection back and then measured the public IPv4 through the configured proxy. That pairing makes it easier to catch a stale selection or an unintended direct route before attributing a search outcome to the intended node.

Preserve the previous selector state before a diagnostic session and restore it during cleanup. Write each completed observation as it happens. Otherwise a timeout can leave the workstation on a test route while also losing the evidence needed to explain the failure.

Save current route
  → Select one diagnostic route
  → Read back selection and observe exit
  → Record the actual browser context
  → Observe the landing state within a deadline
  → Persist evidence
Restore the original route during cleanup

Check the context seen by the page

The source aligns five categories: IP address, language, time zone, geolocation, and WebRTC-related address information. This is best read as a consistency check. It is not a documented formula for Google's risk decision, and agreement between these fields does not establish that the rest of a session looks ordinary.

Configuration intent and observed behavior are different evidence. A saved profile can show what a tool tried to apply; page-visible values and network observations show what reached a particular boundary. Browser-level injection and protocol-level emulation can also overlap. Record the effective state after initialization instead of assuming that two layers necessarily reinforce one another.

The same distinction applies to geographic data. Keep the provider, lookup timestamp, returned location, and browser settings together. If two observations disagree, preserve both values rather than overwriting one with whichever result fits the current hypothesis.

Classify the landing state before counting success

An HTTP response or a loaded document is not enough to identify a successful search. The source looks for result headings, unusual-traffic signals, consent pages, and reCAPTCHA frames. Nested documents matter: MDN describes iframe documents as child browsing contexts, which browsingContext.getTree returns under their parent. A detector limited to the top document can miss the state it is trying to classify.

Treat the source's DOM selectors as observations about the tested page version. Result layouts and challenge markup can change. A missing selector should produce an unclassified observation with retained evidence, rather than automatically becoming a success or an IP-reputation failure.

The grid count needs particular care. The source did not click the checkbox and reported zero image grids. That establishes only that no grid was observed at the stopping point. A checkbox challenge and an image-grid challenge are distinct states; a blocked run does not prove which interaction would have appeared next.

• Results: recognized result content and no observed challenge signal.
• Challenge observed: a challenge frame or visible prompt, whether or not result content also exists.
• Blocked without a detected challenge: an unusual-traffic or blocking page with no challenge found by the detector.
• Consent pending: the session has not yet reached the search outcome being measured.
• Unclassified or timed out: the observer lacks enough evidence to assign another state.

Save the evidence behind each label

The source describes a per-run report, a landing screenshot, and separate browser-profile directories. Those artifacts answer different questions: the report compares runs, the screenshot preserves what was visible, and the profile records the intended configuration. None alone establishes the cause of a remote decision.

An observation record should connect them with a run identifier. Include the final URL, elapsed time, detector version, result count, observed challenge type, and paths to supporting artifacts. Keep requested configuration separate from observed values, and use an explicit unknown value where a measurement was not taken.

The example below contains only fields recoverable from the published Hong Kong row plus attribution. It is a compact representation of that report, not a new execution trace or a reconstruction of the author's complete report.json.

{
  "provenance": "Reported by 如意 / 如意私塾; not independently rerun",
  "experiment_date": "2026-09-16",
  "query": "claude",
  "region": "Hong Kong",
  "exit_ipv4": "141.11.146.74",
  "timezone": "Asia/Hong_Kong",
  "locale": "zh-HK",
  "outcome": "results",
  "result_count": 8
}

What the 50–50 split can tell us

The strongest conclusion is that these ten route-and-profile combinations had different observed outcomes. Network reputation is a plausible contributor: Google's own help page explains that unusual traffic from a shared network, VPN, or provider can affect users of that network. The published sample, however, does not separate reputation from geography, timing, profile differences, or other unmeasured factors.

The source highlights a successful German exit and a blocked British exit in address ranges it associates with the same provider. This is a useful pair for follow-up investigation. Similar-looking addresses and shared provider attribution do not create a controlled experiment or prove that the two exits have equivalent traffic histories.

The reported redirects to google.com.hk also deserve a narrow reading. They are navigation observations. They do not, by themselves, expose Google's internal location classification or prove that a disagreement between geolocation databases caused a challenge. Google documents several inputs to search location, including IP-derived information and settings; record the final URL and the location shown on the results page as separate fields.

A ten-run sample cannot establish that datacenter exits always fail half the time, that a region is intrinsically reliable, or that residential addresses guarantee access. A broader diagnostic would need repeated, authorized observations across independent sessions and times, with the changing conditions recorded explicitly.

Turn the experiment into useful diagnostics

Use a challenge outcome to stop and inspect the session, rather than to trigger an unbounded retry loop. Check routing, context, consent, and detection separately. For systems you operate or are authorized to test, a bounded observation with a clear failure category is more useful than a single success-rate number without supporting evidence.

The practical contribution of this experiment is its comparison structure: identify the actual exit, retain the effective browser context, classify the page that appeared, and save each result before moving on. Its limits are equally useful. They show where a repeatable engineering record ends and an explanation of a third party's risk model remains a hypothesis.