Choosing HTTP Evidence: Gateway Records vs App Logs

Web monitoring starts with a purpose, not a capture point. Counting active clients, timing an API call and reading message bodies each require different evidence and different privacy decisions. A gateway that forwards protected HTTPS sees connections rather than page content. Choosing the wrong layer yields data that looks rich and answers nothing.

Name the question before the data source

Begin with the operational decision the data must support. Availability questions need counts and timings, request questions need paths and status codes, and content questions need message bodies. Every step inward adds sensitivity and engineering complexity. Get the service owner and the security owner to approve audience, purpose and handling before collection starts, because operating the tunnel is not that decision.

Write the question in one sentence and keep it next to the collection plan. It is the only reliable scope control.

What the gateway can and cannot show

A gateway forwarding correctly protected HTTPS normally sees addresses, ports and volumes, not request lines or bodies.

conntrack -L -d 203.0.113.10 | head
tcpdump -ni vpn0 -c 20 'tcp port 443'

The conntrack listing shows flows and translations, and the short capture shows packets without readable application content. That is enough to answer whether traffic flows, how much, and between which endpoints. It is not a list of URLs, and an ordinary CONNECT proxy relays the encrypted exchange without terminating application TLS. When someone promises request paths from that position, ask which component decrypts and under whose trust.

Application logs answer most request questions

For an application you operate, its own supported logging usually answers the request-level question without decrypting anyone else's connections.

curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://app.example.com/health
tail -n 5 /var/log/nginx/access.log

The health request measures availability from a client's position, and the access log records the fields the server already chose to keep. Select the fields the task needs and leave the rest out, because even a URL can carry sensitive parameters. A log line is evidence about that service, not about every other service the user reached through the tunnel. Keeping collection narrow also keeps the retention question small, so set a window shorter than the thought experiment that produced the requirement.

Interception is a separate trust design

If message-level inspection is genuinely required, TLS interception creates a new trusted endpoint and a client trust arrangement that must be distributed and maintained. Applications that pin certificates will break, and the operator now holds private keys whose protection matters as much as any server key. Making collection work by weakening certificate validation, or by patching an application that pins its certificates, trades a security control for a log line. Prefer a documented inspection design whose trust distribution is already managed, and keep the authority's private key out of anything shared.

At the end of the collection window, remove the configuration and its trust material through their owners, and dispose of retained evidence under the agreed policy. Enough reliable information for the stated purpose is the success criterion, not the largest possible capture.