HLTV fetching: 422 with target selectors, Cloudflare challenge without selectors, intermittent success with fresh HTML

Hello, I am experiencing intermittent failures when reading public HLTV pages through the hosted r.jina.ai service.

Could you help determine whether this is an upstream access limitation, a cached challenge page, or an issue related to fetching/rendering options?

Environment

• Test date: September 18, 2026.
• Requests were made without a Jina API key, login cookies, or proxies.
• This is a small personal monitoring project, normally checked every 15 minutes, with bounded retries.

Affected pages

Reproducible match-list URL:

https://www.hltv.org/matches

Reader request URL:

https://r.jina.ai/https://www.hltv.org/matches

We also tested an HLTV news article with article ID 45540. The news-page observations are described below.

Test 1: HTML response with a target selector

For the match-list page, we sent these headers:

Accept: text/plain X-Respond-With: html X-Cache-Tolerance: 300 X-Timeout: 45 X-Target-Selector: [data-match-wrapper]

The response was HTTP 422. The error reported that no content was available for the target selector.

The news-page request used the same options, but with:

X-Target-Selector: .newstext-con

That request also returned HTTP 422.

Test 2: Remove the target selector

Without X-Target-Selector, requests sometimes returned HTTP 200, but the returned HTML was a Cloudflare verification/challenge page rather than the actual HLTV content.

Therefore, HTTP 200 alone did not indicate a successful fetch.

One possible explanation is that the selector-based request was searching inside the challenge page, where the expected content does not exist. However, we cannot confirm this without hosted-service logs.

Test 3: Fresh full-page HTML with default waiting behavior

We tried the following headers:

Accept: text/plain X-Respond-With: html X-No-Cache: true

We omitted X-Target-Selector, X-Timeout, and X-Cache-Tolerance.

For the same news article, this configuration returned real article HTML on two tests. Our local parser extracted seven text paragraphs and two article images.

However, a later request using this configuration returned a verification page again. This was intermittent success, not a reliable fix.

The match-list page still returned a verification page with this configuration.

Control checks

• Reading https://example.com/ through Reader succeeded.
• An ordinary direct HTTP request to the tested HLTV news article succeeded.
• The direct article HTML contained the expected .newstext-con container.
• Direct access to the HLTV match-list page also encountered a challenge, so we are not claiming that every failure is specific to Reader.

Expected behavior

Retrieve the actual public article or match-list content when supported.

If upstream verification prevents retrieval, a clear indication of that limitation would help distinguish it from missing page content or a selector problem.

Questions

1. Can you inspect the hosted fetching logs for the match-list URL and identify why the verification page is being returned?
2. Could caching or rendering/waiting behavior explain the intermittent news-page success?
3. Is there a supported anonymous request configuration for these pages, or is HLTV currently an unreliable/unsupported target?

I understand that upstream access restrictions may be outside Reader's control. Any clarification would be appreciated.

Thank you.