How to Identify Cloud, Hosting, and Crawler IPs in Access Logs
Investigate access-log IPs against cloud provider feeds, hosting ASN prefixes, CDN networks, and published crawler ranges without mistaking infrastructure for intent.
An unfamiliar IP in an access log is not an answer by itself. The useful question is whether the address falls inside a network published by a cloud, hosting, CDN, service, or crawler operator—and what the requests from that address actually did.
Infrastructure is evidence, not intent. A DigitalOcean, AWS, Hetzner, or OVHcloud match can explain where traffic originated, but it does not prove the visitor was a bot or that the request was malicious.
Start with the right source IP
Before running a cloud or hosting IP lookup, confirm which log field represents the client. If a site sits behind Cloudflare, Fastly, a load balancer, or another reverse proxy, the socket address may identify that intermediary. Use the client-IP field produced by a trusted proxy configuration. Do not blindly trust an X-Forwarded-For value supplied by any Internet client.
The Bug Days access-log analyzer accepts Nginx and Apache common or combined logs plus JSON Lines. It counts requests, paths, errors, time buckets, and normalized client IPs. Query strings are removed from shared path summaries.
Official ranges and BGP origin ranges answer different questions
| Evidence | What it supports | What it does not prove |
|---|---|---|
| Official provider feed | The operator published the CIDR for a named cloud service, CDN, GitHub function, or crawler. | The identity or intent of a specific customer using that address. |
| Current BGP origin | The prefix is currently originated by an autonomous system associated with a hosting provider. | A product, tenant, physical visitor location, or malicious behavior. |
| Special-use range | The address is private, loopback, documentation, link-local, multicast, or otherwise non-public. | A routable Internet source. |
| No match | The address did not match the checked datasets. | That the address is residential, human, or safe. |
Bug Days labels those evidence types separately. Cloud and crawler feeds come from the named operators. Hosting coverage uses current originated prefixes from the RIPEstat RIS Prefixes API, which is based on routing data rather than a hand-maintained static list.
Run a bulk cloud and hosting IP lookup
- Paste one IP, a column of addresses, or text containing IPv4 and IPv6 values into the bulk IP lookup.
- Review the primary classification: cloud, hosting/VPS, CDN/proxy, service network, crawler, special-use, or unmatched.
- Open an address to see every matching CIDR, provider, service, published region, and evidence method, plus optional live ASN, ISP, approximate geolocation, and reverse DNS.
- Filter by provider or classification. Repeated addresses remain counted, so a noisy source is easy to spot.
- Share the filtered investigation or export it as CSV, Excel, JSON, or a printable PDF.
The lookup covers official data from AWS, Microsoft Azure, Google Cloud, Oracle Cloud, Cloudflare, Fastly, GitHub, Zscaler, iCloud Private Relay, Tor exit nodes, Google crawlers, Bingbot, GPTBot, OAI-SearchBot, ChatGPT-User, and OAI-AdsBot. Hosting/VPS coverage includes current BGP origin prefixes for DigitalOcean, Hetzner, OVHcloud, Vultr, Linode/Akamai Connected Cloud, Hostinger, Contabo, Scaleway, UpCloud, IONOS, Leaseweb, Rackspace, and Starlink.
Use behavior to decide what matters
After identifying the network, return to the requests. A provider match becomes useful when combined with volume, timing, status codes, and paths:
- Many requests for
/.env, login pages, or unrelated CMS paths often indicate broad automated scanning. - A burst of 404 and 403 responses from one hosted address may deserve a rate limit, but check legitimate integrations first.
- A crawler-range match should be compared with the operator’s verification guidance and the observed user agent. An easily forged user-agent string is not sufficient verification.
- A Cloudflare or Fastly match usually means the logged field captured an intermediary instead of the original client.
- A published cloud region describes a provider range, not the physical location of a person.
What leaves the browser
The analyzer extracts unique normalized IP addresses locally and sends only those addresses to the Bug Days range lookup API. Raw log lines, request paths, query strings, headers, and user-agent strings are not part of the lookup request. Matching results return as a small set of CIDRs; counting, timing, filtering, and report construction remain in the browser.
When you choose one public address for details, only that selected IP is checked with IPWhois.io for live ASN, ISP, and approximate geolocation and with Cloudflare DNS for its reverse-DNS PTR record. The complete log and bulk IP list are not sent to those enrichment services.
This design also avoids downloading a multi-megabyte global prefix catalog for a lookup that may contain only one address. The report records the dataset timestamp and evidence used, so a shared result can be interpreted later.
Share a finding without sharing the whole incident
Use the address-detail share button when a teammate needs one finding. Use the main share button after filtering when they need a provider group or suspicious subset. Shared reports contain the visible IP evidence and summary totals, not the original pasted log. If IP addresses themselves are restricted in your environment, export the report to your approved internal channel instead.