Python's Per-Call TLS Handshake, Not Slow APIs, Caused False Latency Readings

A developer spent 48 hours investigating an apparent performance gap between curl and a Python probe hitting the same local health endpoint. While curl reused a single TCP and TLS connection across its run, the Python loop using urllib.request.urlopen() opened and closed a fresh connection on every iteration, adding handshake overhead each time. The discrepancy had nothing to do with the network, DNS, proxies, or the upstream API — all of which returned consistent HTTP 200 responses throughout. The root cause was a measurement design flaw: connection setup costs were being recorded as origin latency. The fix is to reuse connections via a persistent session object, which avoids repeated TLS handshakes and produces accurate timing data.