Akamai Bot Manager and Carrier IP Traffic

Akamai protects many airlines, banks, retailers and ticketing sites, which makes Bot Manager the system automation builders most often meet on high-value pages. It also tends to guard the pages that matter most to a business, like fare search, account login and checkout. Its responses are not always an obvious block: a request might be slowed, served a cached or alternate page, or quietly tarpitted. That makes debugging hard if you do not know the model. Here is the public picture of how Bot Manager classifies traffic, what changes when your worker exits from a dedicated US carrier line, and how to build monitoring and research jobs that fit inside what the site owner allows.

Three layers: known bots, client telemetry, behavior

Akamai describes Bot Manager as working in layers. First is a directory of known bots, the search crawlers, SEO tools and monitoring services that identify themselves, which site owners can allow, slow or deny by category. Second is detection of unknown bots, which leans heavily on a client-side script that collects telemetry from the browser: device and rendering characteristics, input events, timing. Results are carried in cookies such as _abck and bm_sz, so a client that never runs the script or cannot keep those cookies consistent stands out quickly. Third is behavioral and anomaly analysis across the session and across Akamai's large edge network.

Site owners then map each classification to an action. Beyond allow and deny, Bot Manager offers responses like delaying the reply, serving alternate content, or tarpitting a connection so it hangs. If your job receives a page that looks right but has stale prices or empty inventory, that may be an action, not a bug in your parser.

What a dedicated carrier line changes

Akamai does use IP reputation and network type. Traffic from cloud ranges, anonymizing services and addresses tied to recent abuse enters with lower trust. A NeonProxies line exits from an AT&T, T-Mobile or Verizon range where each address is shared by many real handsets through carrier-grade NAT, and the line serves one customer, so no stranger's attack traffic is attached to it. For honest research jobs that were being penalized purely for coming from a VM, that is a meaningful difference.

It is still one layer out of three. The telemetry script sees your browser, not your network. The behavior models see your pacing and navigation, not your ASN. A mobile IP paired with a headless browser that reports impossible screen metrics or clicks at machine speed will be classified by the other layers regardless.

Habits that keep research jobs welcome

Airline fare tracking and retail price monitoring are the classic legitimate cases, and they work best at modest frequency: a handful of routes or SKUs checked on a schedule from the metro that matters. If you need volume, ask the site for a feed or an API. Many Akamai customers publish partner data programs precisely so they can let known consumers in by name through the bot directory rather than guessing at anonymous traffic.

• Run a full browser for sites that depend on the client script, and let it execute normally.
• Keep one persistent profile and cookie jar per line so session state stays coherent.
• Visit pages the way a reader would reach them, with realistic gaps, instead of enumerating IDs.
• Collect only what the job needs, and cache aggressively so you ask for less.
• Treat slowed, alternate or empty responses as a signal to back off and review.

Reading the failures

An Akamai block page usually carries a Reference number. Log it along with the URL, time and exit IP, and stop the task. A hanging connection that never completes is often a tarpit, so give requests firm timeouts and count them as a stop signal rather than a network fault. A sudden change in content quality with no error is the hardest case; compare a manual load through the same line in a normal browser before deciding anything. If the manual load looks fine and the worker's does not, the difference is in the client, which is where your fix belongs. Keep a small table of each target's normal response size and key fields so the job can flag drift automatically, and review those flags daily instead of letting a quiet degradation run for weeks.

Setting up a Akamai Bot Manager proxy on NeonProxies

1. Choose a line in the metro whose prices or availability you monitor and note its credentials.
2. Point a persistent Playwright or Puppeteer profile at the line so cookies survive between runs.
3. Browse the target once by hand through the line to see normal content as a baseline.
4. Schedule the job at a modest interval and give every request a firm timeout.
5. Log Akamai reference numbers, timeouts and content anomalies to a review channel and pause on them.
6. Ask the site about a data feed or allowlisting if the job needs more volume.

Akamai Bot Manager proxy questions