How to Investigate an IP Address

What is the investigation workflow?

1. Preserve the event time and the evidence captured at the observation point.
2. Verify the client address and the trusted proxy path used to derive it.
3. Recognize private and other special-purpose addresses before interpreting public network data.
4. Run the lookup and record its separate lookup time, result URL, and any generic source name, data version, or build identifier that is available.
5. Read the available sections and compare them with what happened, such as repeated failed logins. Choose an action that matches the evidence and its impact.

Event time and lookup time answer different questions. A current lookup describes the information available when you look, not necessarily the registration, routing, DNS, tag, or location state at the time of the event.

What evidence should you preserve?

Save the event before additional lookup information (enrichment data) changes. A source is the sender; a destination is the recipient. A port is a number distinguishing an application or exchange of data at an IP address. A protocol, such as TCP or UDP, defines how the traffic is exchanged. The observation point is the system that recorded those details. At minimum, keep the precise UTC timestamp, observed source address and port, destination address and port, and transport protocol captured at the same observation point, plus a non-secret request or event identifier. Keep the relevant action and outcome, such as the requested route, authentication result, or rule that triggered an alert.

{
  "occurred_at": "2026-08-23T09:41:27.318Z",
  "edge_client_ip": "203.0.113.24",
  "edge_client_port": 53144,
  "edge_destination_ip": "198.51.100.10",
  "edge_destination_port": 443,
  "edge_transport": "tcp",
  "observation_point": "public_edge",
  "request_id": "01K35P9D3T6M7N8P9Q0R1S2T3V",
  "route": "/login",
  "outcome": "rate_limited"
}

Do not log raw credentials (like user passwords) or session tokens.

If traffic passes through a content delivery network (CDN) or reverse proxy, capture the public connection details at that service's Internet-facing server (the edge). A CDN serves content through distributed servers; a reverse proxy receives requests on your website's behalf.

See what to log for reliable IP investigations.

Is this really the client IP address?

Verify the immediate peer and accept forwarding data only through proxies that sanitize it. Do not assume the leftmost X-Forwarded-For value is the client. Follow the safe client-IP workflow and the right-to-left X-Forwarded-For algorithm.

Can this address be a public client?

Classify the address before interpreting registration or location. Private, loopback, link-local, documentation, multicast, and other special-purpose ranges have defined meanings and may not represent a public Internet client.

• A private address in a public application log often indicates a proxy-logging problem.
• A documentation address such as 203.0.113.24 should appear in examples, not real public traffic.
• A shared CGNAT address can be valid inside a provider network but is not globally reachable.
• An IPv6 link-local address applies only on its local network link.

Use the reserved and special-purpose address reference.

How should you read the IP Lens result?

Use a stable reading order. The 208.67.222.222 result is a useful worked example, although its visible sections can change as the available data changes.

1. Special-purpose handling: a search for a special-purpose address redirects to the result for its reserved block; an ordinary address result has no separate status row.
2. Registered Owner, when present: the organization listed in number-resource records, not necessarily the user or legal owner.
3. Network, when present: the ASN and prefix observed in the routing information currently available in IP Lens, not the connection's complete path.
4. Pointer name and visible tags, when present: descriptive clues that can be stale, delegated, shared, or wrong.
5. IP Location, when present: estimates from named sources, not a street address or proof of where a person is.

Use How to Read an IP Address Lookup Result for every field. Pivot to the prefix or ASN when repeated activity suggests a broader network pattern, but do not assume that all addresses in that range belong to one actor.

What other evidence should you compare with the address?

Network context becomes useful when it supports observed behavior. Compare the event with other requests, non-secret request IDs, authenticated account history, device or browser security signals, rate-limit events, and the exact action attempted.

How should you choose an action?

Start with the narrowest control that addresses the observed behavior: monitor, require an additional verification step, rate-limit the action, block one address temporarily, or report documented abuse. Expand to a prefix or provider only after proving related activity across that scope. A routing or allocation boundary can contain many unrelated customers.

For IPv6, an outside observer usually cannot infer a customer's delegated boundary from one address. Do not assume that /64 identifies one customer. Use provider-specific evidence and prefer narrow, temporary enforcement.

If another network needs to act, continue with How to Report Network Abuse Associated With an IP Address.