A scraper can change IP addresses between requests. Residential proxies let it send traffic through home and mobile networks, mixing with the connections a website sees from customers.
For teams managing AI and LLM web scrapers, that raises a practical question. How do you follow the same automation when its network address keeps changing?
The workload behind this case remains unidentified. We followed one trail through Peakhour's request logs. It started with a page request, took a detour through Alibaba-hosted infrastructure, and left us with a number that kept appearing.
It started with a page request
A visitor requested a page. Peakhour asked the browser to complete a challenge before continuing.
The first requests were spread widely. In the group we followed, they came from 103,271 IP addresses across 182 countries. Some used residential proxies. Others came from hosting networks and other connections.
We selected 113,253 sessions where a challenged page request was followed by a challenge submission from Alibaba's network. We used each site's session records to follow the two steps together. The main window ran from 26 October 2026 at midnight to 27 October at 11:30 am AEDT.
Then we looked at where the answers came from.
The answer came from another network
About a second and a half after a page request, its challenge answer arrived from an Alibaba-hosted address.
That switch happened in 111,035 sessions, or 98.04% of the selected group. Both the IP address and the network changed. The median delay was 1.481 seconds.
The original requests were spread around the world. 98.55% of first challenge submissions came from IP addresses recorded in Singapore.
The network change gave us a way to follow the traffic. The page request and its answer still belonged to the same site and session.
Our residential proxy research describes how different requests can leave through different networks. Here, 4,530 distinct original IPs had an explicit residential proxy label. The remaining addresses had other labels or an unknown proxy status.
The next question was how widely the submissions were spread inside Alibaba's network.
Four ranges kept appearing
Four address ranges carried 99.90% of Alibaba validation requests in the main window.
| Observed range | Validation requests |
|---|---|
43.119.100.0/24 |
960,598 |
47.82.201.0/24 |
829,742 |
47.82.202.0/24 |
266,546 |
43.119.104.0/24 |
266,115 |
Each /24 contains 256 IPv4 addresses. These counts include repeated submissions.
Alibaba identifies the hosting network in the records. The customer operating those addresses remains unknown.
We now had a wide spread of page requests feeding into a small set of submission networks. We checked what else changed along the way.
The browser name stayed the same
Every paired session kept the same User-Agent string and requested path between the page request and the first challenge submission. The User-Agent is the browser name and version a request reports.
In 98,886 sessions, the TLS fingerprint changed. A TLS fingerprint describes how a client sets up an encrypted connection.
This was the most common pair of fingerprints:
| Request stage | TLS JA4 fingerprint |
|---|---|
| Original page request | t13d1516h2_8daaf6152771_d8a2da3f94cd |
| Challenge submission | t13d521100_b262b3658495_8e6e362c5eac |
The same browser name travelled across a changed network and a changed connection fingerprint. That fits separate software handling the submission, or different proxy routes for different requests. The records leave that choice open.
Our article on residential proxies and anti-detect browsers explains how network routing and browser presentation can change separately.
Our guide to network fingerprints in bot and rate-limit decisions explains how those connection details help group requests.
Then we counted the submissions in each session.
The number was twenty-one
107,454 sessions made exactly 21 challenge submissions.
We took one sequence apart. Twenty-one submissions arrived through twenty-one Alibaba-hosted IP addresses. Each carried the same challenge answer, browser identifier and browser-data payload.
The address changed with each request. The answer kept coming back.
We could match challenge-response records for 107,298 of the exactly-21 sessions. Every matched session reused one challenge answer and one browser identifier.
There was also a clue in the response: HTTP 307, a redirect that preserves the request method. A client following it can send the POST again.
The Fetch redirect algorithm stops after 20 followed redirects. One initial POST plus 20 redirects would produce the familiar twenty-one.
That explains a possible route to the repeated count. The client implementation remains unknown, and some sessions had shorter bursts. The repeated answer was the detail we could follow across them.
The answers connected the four ranges
A narrower follow-up found 25,421 unique challenge answers submitted through all four address ranges.
All four ranges stayed active in every five-minute period of that follow-up. Shared answers linked the submissions directly. The repeats also helped explain why their traffic rose and fell together.
We had followed the pattern across networks. Next, we looked backward in time.
We found the same trail in April
A saved session from 15 April 2026 showed the same network switch and the same pair of TLS fingerprints. It submitted an identical answer 20 times through 18 Alibaba-hosted IPs.
By October, the volume was much larger. Alibaba-attributed validation requests averaged 88,778 a day on 1–17 September and 1,862,584 a day on 18–26 October. The busiest full day, 20 October, had 2,653,940 requests.
The callout marks 20 October: 2.65 million Alibaba-attributed requests, or 60.23% of validation traffic. The dashed line shows Alibaba’s share. Open the chart for a larger view.
Those counts include retries. The chart's final day ends at 11:30 am AEDT and is incomplete. The repeated submissions had become a large part of the traffic we were following.
That left the question a website owner would care about most: what happened to the requests for pages?
Open the supporting charts and notes
What the saved validation counts show
The main response records attributed to Alibaba contained 2,305,119 accepted submissions and 49 rejected submissions. Repeated answers contribute many records to those totals. Keep these validation-service counts separate from the final request outcome and the count of independently solved challenges.
The narrower four-pool follow-up excluded every hostname containing edge. It found 30,518 distinct challenge identifiers in response records and 626,080 accepted response records. Answers for 30,498 of those challenges appeared across multiple IPs.
These counts describe different groups from the main 113,253-session analysis. In the narrower follow-up, 30,217 of 30,487 sessions had at least ten minutes of observation after the first redirect.
The static figures below preserve the remaining views from the saved reports, including the residential-proxy subsets and the comparison samples. Each uses its original population and window. They should be read separately rather than added together.
Where the first answers arrived
The recorded IP country was Singapore for 98.55% of first challenge submissions. This describes the network exit.
Original requests with a residential proxy label
This subset uses explicit labels in the saved data. An unlabelled address is not automatically a direct connection.
Where the labelled subset sent its first answers
The country is the recorded location of the submission IP. This does not locate the browser.
The labelled residential proxy subset
One original and first submission per paired session. Site aliases match the main flow chart.
Browser and header candidates across five samples
Five separate 30-minute samples. The compound browser/header candidate matched 7,991 of 8,104 Alibaba-attributed session-window observations and zero of 188,914 other-network observations. Network groups are not malicious and legitimate labels; these results do not establish a false-positive rate.
Individual signals also appear on other networks
SwiftShader, version conflicts and missing browser headers each occur outside the selected network. The compound rule describes separation in these samples, rather than a proven block policy.
Connection timing within paired sessions
The plotted change is original minus first-submission timing. Among 6,355 same-service-location pairs, the median TLS reduction was about 236 ms. TCP changed little. Every hostname containing edge was excluded.
Timing in the labelled residential proxy subset
The TLS reduction was about 206 ms in the labelled subset. These timing values support a connection-path difference and cannot locate JavaScript execution.
Timing comparison groups overlap
The full-window Alibaba group and two 30-minute comparison groups have different coverage. Their overlap shows why a timing threshold alone is insufficient.
Address use within the four ranges
The chart preserves the observed address layout. It does not count virtual machines, containers or operators.
A wider search found the same submission pools
A search using browser and header traits, without requiring a provider, country or one TLS fingerprint, found 2,302,914 matched submission records. The four bars show the 2,302,913 in-pool matches. The single outside-pool match was rejected and is excluded from those bars. This search still follows a known profile.
Reported CPU counts followed a regular pattern
The browser payload reported every even value from 64 to 192. These are reported properties, rather than measurements of physical hardware.
What the four pools sent
In the narrower follow-up, 99.63% of pool requests were challenge submissions. The API/JSON category is inferred from paths and headers; it does not establish data retrieval.
The Lightpanda lead remained weak
A separate 20 October to 27 October sample contained 4,271 labelled requests. Close shared-exit matches did not establish a matching site-and-URL request sequence. Shared exits can carry unrelated traffic.
All four pools stayed active
Five-minute activity in the narrower follow-up window, labelled in UTC. Shared repeated answers explain some of the timing agreement.
The selected browser profile recurred over time
This series requires the selected User-Agent, SwiftShader and square viewport. Counts are challenge-response records, including repeats, in UTC daily buckets.
Matching traffic continued in our observations
The vertical reference comes from the separate public report. Continued activity at our sites cannot establish that its reported shutdown was wrong or that both observations have one operator. Times are UTC.
The browser claim appeared before the traced replay
This is the selected User-Agent string across all networks. The log scale plots zero counts at 0.5. The string alone cannot establish that earlier requests belonged to this workload.
Missing network names changed the view
Network names were blank in all challenge-service responses from 17 October onward. Edge request records still showed Alibaba traffic. A missing label must remain unknown.
How we followed the trail
The main investigation covers 26 October 2026 at midnight to 27 October at 11:30 am AEDT. We paired the original request and first submission by site and session. We linked each challenge decision to its exact request identifier, then checked the times and addresses.
Historical charts combine daily edge counts with separately labelled challenge-service records. Some service records lost their network name while edge records continued to show the traffic. We kept missing network labels unknown.
Timing comparisons use requests handled at the same service location and exclude every hostname containing edge. The timing describes the connection path. The location of the software running the challenge remains unknown.
We also checked leads from FlagThis's September crawler investigation. Shared browser traits and network exits left the operator and software unidentified, including the Lightpanda lead.
Customer names are replaced with consistent site numbers. Raw session identifiers and challenge answers stay private. All 28 figures retain their original values and groups.
We followed the requests past the challenge
Among the 107,454 exactly-21 sessions, we found no later ordinary page GET in the same site and session during the observation window.
The broader group included 2,152 sessions with a later ordinary GET. Those later GETs came from sessions with a different submission count. We kept the two groups separate.
The narrower follow-up showed requests trying combinations of search filters across 20,213 distinct URLs, with query parameters put in a consistent order.
We checked for a later request to the original challenged URL, or one referring to it. That follow-up found no match within its available window, capped at ten minutes. Requests using new sessions or arriving later fall outside that check.
The traffic showed us the pages it was trying to reach. We followed the repeated answers to the final request decision.
How Peakhour blocked the replay
Peakhour blocks challenge reuse by default. It checks the challenge identifier and rejects a repeat, even when the submission arrives from another IP address.
That default protection blocked the replayed requests in this case. Each replay still carried an already-used challenge through every change of address.
