Diagnosing hosted web open failures: public URL returns inaccessible, marked request absent from bounded server logs

[bamnenim-permissionlabs]

Question

How can a site operator distinguish a hosted web-reader cache/index/access decision from an attempted live fetch that fails before the application, when the only error is URL ... is not accessible via this tool? Is there a supported way to obtain a provider-side trace or effective access mode for a specific URL and UTC timestamp?

Related reports: #49516 and #51196. I am asking here rather than filing another potentially duplicate bug.

Public reproduction

Use ordinary web search/page retrieval (not cloud browser, computer use, or shell fallback) to open:

https://opentoinfluencer.com/compare/api

Ask which occupancy conditions are supported and when HTTP 422 is returned.

Observed:

URL https://opentoinfluencer.com/compare/api is not accessible via this tool.

The destination HTML and public JSON also fail:

• https://opentoinfluencer.com/compare/da-nang
• https://opentoinfluencer.com/api/price-search?destination=da-nang

Environment: macOS 26.3 arm64; installed CLI reports codex-cli 0.162.1. The latest controlled trace below is from the hosted web tool in a Codex session; the installed CLI version is not claimed to identify that hosted backend. Earlier explicit web_search="live" CLI tests also failed. Whether the hosted backend applied that mode is unknown.

Bounded controls — 2026-10-14 UTC

At 02:50:37.637 UTC, hosted open attempted:
https://opentoinfluencer.com/compare/api?utm_source=oti518_trace_20261014_native

It returned the same inaccessible error. Bare /compare/api failed too; /en returned (400) Timeout fetching.

During a 02:50:11–02:51:52 UTC Worker log session:

• Direct Python GET controls immediately before and after the hosted attempt returned HTTP 200, and both distinct control markers appeared in the Worker logs.
• The hosted marker did not appear. No tail sampling warning was observed.
• After analytics ingestion time, the Cloudflare edge query for 02:49–02:52 UTC contained the two controls (HTTP 200; returned groups' sampleInterval 1), with no other target-path or ChatGPT-User/OAI-SearchBot-UA request. A corresponding filtered firewall-events query was empty.
• These are bounded/adaptive observations. Missing records do not prove no edge arrival or no live request. Unknown prerequisite requests and other user agents remain uncorrelated.

Additional controls:

• Direct HTTP retrieves the target HTML, documentation and JSON with 200, no redirects or cf-mitigated header. Documentation is about 4 KB.
• In the same earlier hosted-tool test, https://example.com/ was readable, but https://example.com/?oti518=20261014-resume was inaccessible; direct HTTP to the exact query URL returned 200.
• Claude WebFetch previously read the public pages. A user also reported successful ChatGPT cloud-browser reading, followed by the same ordinary-web error in the already-authorized conversation. That ChatGPT result is user-reported, not an independently captured raw tool trace.
• No security protections or account settings were disabled for these tests.

What would help

Please advise how to determine:

1. Whether a live fetch was attempted or a cache/index/access decision stopped it.
2. The effective hosted access mode, prerequisite requests and redirect chain.
3. Any upstream HTTP status, DNS/TLS/connect error, request identifier, or actionable site-side requirement.

We have not established a WAF cause, an indexing cause, or a shared root cause with the related reports. Browser success is not treated as a hosted-reader fix. No credentials, visitor records, private source code, raw server logs, or conversation identifiers are included.

[bamnenim-permissionlabs]

Additional controlled URL comparison (2026-10-14 UTC):

• Hosted open reads https://opentoinfluencer.com/vi/terms and the #terms variant (normalized to the bare URL), but fails on https://opentoinfluencer.com/vi/terms?utm_source=oti518_samecontent_20261014 .
• Direct HTTP GET of the bare and query URLs returns 200 with no redirect. Both have the same private, no-cache, no-store, max-age=0, must-revalidate header and identical extracted visible text (16,662 characters; matching SHA-256). Raw HTML differs, so this is not a byte-identical response claim.
• As an external control, hosted open reads https://developers.openai.com/api/docs/guides/tools-web-search?trk=article-ssr-frontend-pulse_little-text-block but reports Cache miss for https://developers.openai.com/api/docs/guides/tools-web-search?utm_source=oti518_samecontent_20261014 .

This does not establish the effective mode or root cause. It does show that domain-wide blocking, visible content, no-store alone, and a blanket prohibition on query strings are insufficient explanations for the observed results. A URL-specific cache/index/access decision remains a hypothesis to distinguish from a failed live request.

Further evidence from 2026-10-14 UTC:

• A user reports that, in the same ChatGPT conversation and ordinary web reader, bare /compare/api fails while bare /vi/terms and example.com succeed; no browser/code fallback. This is user-reported, not an independently inspected ChatGPT tool trace.
• A bounded Cloudflare adaptive query covering 03:50–04:05 UTC shows ChatGPT-User requests from IPs matching OpenAI’s published ranges: apex /en returned200 at03:57 and apex /vi/terms returned200 at03:58. No comparison-path request appears among the six returned groups. No unique correlation marker links these requests to that user conversation, and adaptive absence is not proof of no edge arrival.
• Readable Vietnamese/Korean terms and failing /compare/api all return200 to ordinary GET and HEAD, valid UTF-8 text/html, no redirect or challenge header. Terms responses also use no-store. The failing docs page is only4,129bytes and has index,follow. Korean /ko/terms is readable in the hosted tool, so Korean text alone does not explain the failure.
• Claude Code WebFetch retrieves docs and comparison HTML; a fresh Gemini guest answer matches a specific current comparison row and observation timestamp, although Gemini UI exposes no raw retrieval trace.

This supports investigating URL-specific eligibility/cache/index/fetch handling rather than a blanket domain block or total inability to make network requests. It does not prove any one cause. We have not changed production security or caching settings. Is there a supported diagnostic to identify the actual decision/failure stage for the comparison URL?

[bomtobe-hgkim]

Your origin-side controls narrow the problem, but an absent origin log cannot identify which upstream step stopped the request. A useful diagnostic from the hosted reader would be a per-attempt correlation ID plus one terminal stage: cache or index result, policy decision, fetch started, or network/HTTP outcome. That would let support distinguish a pre-origin decision from a live-fetch failure without guessing at WAF or indexing. Include the UTC timestamp and normalized host/path in the report, while keeping credentials and visitor data private. I haven't investigated this specific reader path; I work on Orke at BOMTOBE.

[bomtobe-hgkim]

The absence of an origin log narrows the fault but does not identify the stage: a reader could deny or serve an index/cache result before origin, or a live fetch could fail at DNS, TLS, or redirect handling before the app. For a controlled test, expose a harmless endpoint that logs a unique nonce and UTC timestamp, then compare a reader request with direct access. If the nonce never reaches origin, only a provider-side request ID plus decision stage and effective access mode can distinguish those paths. Include the canonical URL, UTC timestamp, redirect chain, and nonce in a support trace request; avoid secrets. I can’t see provider traces from here. Disclosure: I work at BOMTOBE on Orke.