How to reliably get peer IP address when using aiohttp client?

[vkruglik-aka]

Please note that the solutions you're likely to run into in google searches and AI are not reliable, and this is why I am asking here.

cc @asvetlov

Knowing peer IP and being able to log it is critical for diagnostics in production systems.

Here is what I tried which isn't reliable:

        async with session.request(method=method, url=url, **kwargs) as response:
            # Get peer IP address for including in result
            peername = (
                response.connection.transport.get_extra_info('peername')
                if response.connection is not None
                else None
            )
            used_ip: str | None = peername[0] if peername else None
            
            raw_bytes = await response.read()

The above isn't reliable because when the response is pretty short such that it's completely read by the time that session.request(method=method, url=url, **kwargs) as response: context is entered, response.connection is already None, so it's impossible to get the peer IP address using the above technique.

What is a reliable technique for obtaining the peer IP which was used in the request?

[alexliluz]

Your observation is correct: there is currently no fully public API that
retains the peer after a response releases its connection. This is the same
gap tracked by aiohttp #4645.

For short responses, registering the EOF callback can immediately call
ClientResponse._response_eof(), which releases the connection before
ClientResponse.start() returns. That is why moving the lookup earlier or to
on_request_end is not sufficient. The tracing API cannot solve it either:
TraceConnectionCreateEndParams currently carries no connection or transport.

A practical workaround is to use the documented response_class session
extension point and snapshot peername at the beginning of response startup,
before the parser can observe EOF:

from typing import Any

import aiohttp


class PeerAwareResponse(aiohttp.ClientResponse):
    peername: object | None = None

    async def start(self, connection: Any) -> aiohttp.ClientResponse:
        transport = connection.transport
        if transport is not None:
            self.peername = transport.get_extra_info("peername")
        return await super().start(connection)


async with aiohttp.ClientSession(
    response_class=PeerAwareResponse,
) as session:
    async with session.request(method, url, **kwargs) as response:
        raw_bytes = await response.read()

        peername = response.peername
        used_ip = (
            peername[0]
            if isinstance(peername, tuple) and peername
            else None
        )

Capture before await super().start(connection), not after it. On a complete
short response, super().start() may already have released the connection by
the time it returns.

This also records each redirect hop because every ClientResponse instance
gets its own snapshot:

for hop in (*response.history, response):
    print(hop.url, hop.peername)

I tested the reproducer against aiohttp 3.14.3 with two short responses on one
keep-alive TCP connection. In both cases response.connection was None
after the response was read, while both peername snapshots contained the
actual selected socket address.

Two operational caveats:

• With an HTTP proxy, this is the transport peer (normally the proxy), not
  necessarily the origin server.
• ClientSession(response_class=...) is documented, but overriding
  ClientResponse.start() is not a separately documented stable interface.
  Treat this as a small compatibility shim, pin/test aiohttp upgrades, and
  follow Access peername info for closed ClientResponse transport? #4645 if you need a first-class retained peer property.

Source paths checked on current master (9bb501f):
ClientResponse.start() / EOF release
and the empty
TraceConnectionCreateEndParams.

Verification disclosure: I used OpenAI Codex to inspect the current aiohttp
source and run the loopback reproducer; the code and observed behavior above
were checked against aiohttp 3.14.3.

[vkruglik-aka]

Wow - thank you for all the details, @alexliluz!

[Dreamsorcerer]

If you want to try and come up with a more direct solution, this PR tried to do something similar, but hasn't reached our requirements to merge yet: #11553

[adarshsm]

The reason the response.connection approach is flaky is that aiohttp hands the connection back to the pool the moment the body reaches EOF. For a short response that happens inside session.request(...), so by the time you reach the async with block response.connection is already None — on 3.14 it's None even for larger bodies, so it's not something you can lean on.

The reliable place to read it is the connector, not the response. TCPConnector.connect() runs for every request — including ones served from a reused pooled connection — and the transport is always live there. Subclass it, read the peername, and stash it in a ContextVar:

import contextvars, aiohttp

peer_ip: contextvars.ContextVar = contextvars.ContextVar("peer_ip", default=None)

class PeerIPConnector(aiohttp.TCPConnector):
    async def connect(self, req, traces, timeout):
        conn = await super().connect(req, traces, timeout)
        peername = conn.transport.get_extra_info("peername") if conn.transport else None
        if peername:
            peer_ip.set(peername[0])
        return conn

async with aiohttp.ClientSession(connector=PeerIPConnector()) as session:
    async with session.get(url) as resp:
        body = await resp.read()
    used_ip = peer_ip.get()      # set reliably, even for a 2-byte body

Why this holds up where the response-side trick doesn't:

• connect() fires on new and reused connections, so you still get the IP when the request came from the pool (overriding _wrap_create_connection misses those).
• It's read at connect time, before any EOF/release, so response size is irrelevant.
• ContextVar is task-local, so it stays correct under concurrency — each task sees the IP for its own request.

Tested on aiohttp 3.14.3: new + pooled connections, 2-byte vs 200 KB bodies, and 25 concurrent requests — peer_ip is populated correctly every time, never None. Same idea works over HTTPS (you get the SSL transport's peername); behind a forward proxy it'll be the proxy's address, which is the real peer.