Ephemeral Port Exhaustion Calculator

Platform preset:

Start from Linux, IANA/Windows, AWS NAT Gateway, Azure NAT Gateway, or Custom.

Source addresses:

Use 1 for a single host, or the number of public/NAT source addresses sharing the workload.

addresses

Ephemeral port range:

Enter the inclusive low and high local port numbers used for automatic outbound binds.

through

New connections:

Use peak connection attempts per second from the app, proxy, NAT, or load test.

conn/s

Hottest destination share: {{ formatPct(result.hottestDestinationSharePct, 0) }}

Estimate what share of total churn targets the busiest single destination tuple.

Connection lifetime:

Use measured average duration for the hot destination, not the request latency alone.

sec

Reuse hold time:

Use 60 seconds for a common Linux estimate, 240 seconds for Windows TIME_WAIT, or a platform-specific NAT cooldown.

sec

Check port model inputs

{{ error }}

Destination endpoints:

Used for the distribution note and JSON payload; the hot-share field remains the primary pressure driver.

tuples

Reserved ports:

Leave 0 unless sysctl, firewall, or NAT policy reserves known ports inside the selected range.

ports/source

Safety reserve: {{ formatPct(result.safetyReservePct, 0) }}

Recommended planning reserve is 20-30%; set 0 only for hard physical pool comparison.

Provider cap:

Use 0 for host/kernel range math, 55000 for AWS NAT Gateway, or 50000 for Azure NAT Gateway.

slots/source

Watch threshold: {{ formatPct(result.alertThresholdPct, 0) }}

Keep 80% for operational headroom; lower it when retry bursts are common.

Decimal precision:

Use 1-3 decimals for capacity reviews; exports keep the same display precision.

Signal	Value	Readout	Copy
{{ row.label }}	{{ row.value }}	{{ row.detail }}

Budget item	Value	Detail	Copy
{{ row.label }}	{{ row.value }}	{{ row.detail }}

Move	Target	Why it helps	Copy
{{ row.label }}	{{ row.value }}	{{ row.detail }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Outbound connection failures can come from source-port pressure even when bandwidth, CPU, DNS, and the remote service look healthy. Every outbound TCP or UDP flow needs a temporary local source port, and that port choice may stay unavailable while the connection is active and while the platform waits before reusing it for the same destination.

The scarce object is a slot in a connection tuple, not just a number in a port range. A flow is distinguished by source address, source port, destination address, destination port, and protocol. The same source-port number can often be used for different destinations at the same time, but repeated connections from one source address to one busy destination need separate held slots until old state clears.

Source network address translation, or SNAT, concentrates this risk because many private clients can share a smaller set of translated public addresses. A container cluster, proxy tier, serverless fleet, or busy subnet may create thousands of short-lived outbound flows while appearing to the outside world as one or a few source addresses.

Connection churn: The rate of new outbound connections, not the number of application requests handled overall.
Hot destination: The single destination address, destination port, and protocol that receives the largest share of new flows.
Held slot: A source-port choice that remains unavailable while the flow is active and during TIME-WAIT or NAT cooldown.
Source inventory: The usable ports available from each source address after platform ranges, provider caps, and reserved ports are considered.

The practical risk rises when high churn, concentrated destinations, and long hold times meet. A service opening 800 new connections per second may be safe when connections are pooled or spread across many destinations. The same churn can become fragile when retries or short-lived clients repeatedly hit one API, database endpoint, mirror, or payment service.

Mitigation usually changes one of the same inputs. More source addresses multiply inventory. Connection pooling, keep-alive, HTTP/2, HTTP/3, and retry backoff reduce churn. A wider host range can help on a local system, but a managed NAT service may still enforce a same-destination cap below the raw port range.

A capacity estimate is not a socket-table inspection. Real incidents still need operating-system counters, NAT gateway metrics, flow logs, firewall state, retry logs, and destination distribution. The estimate is useful because it shows whether source-port pressure is plausible before time is spent chasing unrelated symptoms.

How to Use This Tool:

Start with the translated source address pool that carries the outbound traffic, then model the busiest destination tuple during the peak window.

Choose a Platform preset. Linux default, IANA or modern Windows, AWS NAT Gateway IPv4, Azure NAT Gateway, and Wide custom host range load starting ranges, reuse holds, and same-destination caps where the preset has one.
Set Source addresses to the number of local source IPs, NAT public IPs, or gateway addresses sharing the workload. Each address adds an independent same-destination port pool.
Check the inclusive Ephemeral port range. If the high value is lower than the low value, the summary changes to Check port model and the result tables show the input issue instead of capacity rows.
Enter peak New connections and adjust Hottest destination share. Use the busiest single destination tuple, not the average across all services.
Enter Connection lifetime and Reuse hold time. The model adds both into Slot hold time, so a short request can still occupy a source port if sockets stay active or the platform delays reuse.
Open Advanced when destination count, reserved ports, safety reserve, provider cap, watch threshold, or decimal precision need to match your environment.
Read Exhaustion Snapshot first, compare Port Budget for inventory assumptions, then use Mitigation Ledger and Reuse Pressure Curve to see which change reduces risk fastest.

Measured peak values are better than averages. Understating hot-destination share, reuse hold, retry bursts, or provider caps can make a risky deployment look comfortably inside reserve.

Interpreting Results:

Planned pool use is the main planning signal because it compares required hot-destination slots with the pool left after the configured safety reserve. Physical pool use ignores that reserve and shows whether the modeled workload can consume the hard source-port inventory.

Required hot slots is the first number to challenge. It rises with Hottest destination rate and Slot hold time, so connection pooling, lower retry churn, shorter hold time, or traffic spread can reduce it directly. Connection-rate headroom shows how much total churn remains before the planned reserve is crossed under the current hot-share assumption.

Hard exhaustion risk means required slots meet or exceed the physical source-port pool.
No reserve left means the workload fits only by spending the reserve that was meant for bursts and measurement error.
Near threshold means planned use has reached the configured watch threshold but not the full reserve boundary.
Within planned reserve means the entered assumptions leave planned headroom for the hot destination.

A green result is not proof that outbound networking is healthy. Confirm the estimate against socket states, NAT or SNAT port metrics, retry logs, destination distribution, provider quotas, and recent platform changes before treating capacity as cleared.

Technical Details:

Temporary source-port capacity is governed by the connection tuple. For TCP and UDP traffic, a flow is distinguished by source address, source port, destination address, destination port, and protocol. Reusing a source-port number for another destination is normally safe, while reusing it too quickly for the same destination can collide with active state, TIME-WAIT, NAT hold-down behavior, or downstream firewall expectations.

The selected range is inclusive. Operating-system ranges and managed-provider limits are not interchangeable: a local range describes which ports can be chosen automatically, while a NAT same-destination cap can be lower than the raw range. Effective inventory per source address is the capped range minus reserved ports. Physical inventory then scales by the source-address count.

Safety reserve changes the interpretation, not the physical inventory. A 20% reserve leaves 80% of the effective pool available for planned load and keeps the rest for bursts, uneven distribution, retries, and measurement error. The watch threshold is tested against that planned pool so a warning can appear before every physical port is consumed.

Formula Core:

The model converts hot-destination connection churn into held source-port slots, then compares that demand with physical and planned port pools.

\begin{array}{lcl} P_{range} & = & P_{high} - P_{low} + 1 \\ P_{limit} & = & min (P_{range}, P_{cap}) when a cap is set \\ P_{source} & = & max (0, P_{limit} - P_{reserved}) \\ P_{physical} & = & P_{source} \times S \\ P_{planned} & = & P_{physical} \times (1 - R) \\ T_{hold} & = & T_{active} + T_{reuse} \\ P_{required} & = & C \times H \times T_{hold} \\ U_{planned} & = & \frac{P_{required}}{P_{planned}} \times 100 \end{array}

C is total new connections per second, H is hottest destination share as a fraction, S is source address count, and R is safety reserve as a fraction. When Provider cap is 0, the selected port range is used directly. When a cap is positive, the smaller value between the inclusive range and the cap becomes the limit before reserved ports are removed.

For a single Linux source address using ports 32768 through 60999, the raw range contains 28,232 ports. With no reserved ports and a 20% safety reserve, planned slots are about 22,586. At 800 new connections per second, a 70% hot share, and a 62 second hold, required hot slots are 34,720, so planned pool use exceeds 100% and physical pool use also exceeds the hard range.

Ephemeral port pressure status rules
Status	Boundary	Meaning
Check port model	Invalid range, no usable physical pool, or no usable planned pool	Correct inputs before using the estimate.
Hard exhaustion risk	`Physical pool use >= 100%`	The hot destination can consume the complete physical source-port inventory.
Reserve exhausted / No reserve left	`Planned pool use >= 100%` while physical use is below `100%`	The workload fits only by spending the reserve.
Hot destination watch / Near threshold	`Planned pool use >= watch threshold`	The estimate is below full reserve exhaustion but close enough to monitor.
Within planned reserve	Planned pool use is below the watch threshold	The entered assumptions leave planned headroom.

Platform preset assumptions for ephemeral port exhaustion estimates
Preset	Range or cap	Reuse hold
Linux default range	`32768` through `60999`, no provider cap	`60` seconds
IANA / Windows modern range	`49152` through `65535`, no provider cap	`240` seconds
AWS NAT Gateway IPv4	`1024` through `65535` with `55,000` same-destination slots per source	`60` seconds
Azure NAT Gateway	`1024` through `65535` with `50,000` same-destination slots per public IP	`65` seconds
Wide custom host range	`10000` through `65535`, no provider cap	`60` seconds

Input bounds for ephemeral port exhaustion estimates
Input	Accepted model range	Effect
Source addresses	Whole number from `1` to `512`	Multiplies same-destination source-port inventory.
Ephemeral port range	Inclusive low and high values from `1` to `65535`	Sets raw ports per source before reserves and provider caps.
New connections and hottest destination share	Non-negative connection rate; visible hot-share range from `1%` to `100%`	Converts total churn into hot-destination connection pressure.
Connection lifetime and reuse hold	Non-negative seconds	Sets how long each hot-destination slot remains unavailable.
Reserved ports and provider cap	Reserved ports from `0` to `65535`; provider cap from `0` to `1000000`	Reduces or caps effective slots per source address.
Safety reserve and watch threshold	Reserve from `0%` to `80%`; threshold from `40%` to `100%`	Defines planned headroom and the warning boundary.

Privacy and Accuracy Notes:

The calculation runs from the values entered on the page and does not perform a live scan of your host, NAT gateway, cloud account, or destination service.

The model does not see actual socket tables, TIME-WAIT counts, NAT flow logs, firewall state, or cloud metrics.
Preset values are planning defaults. Check the current operating system, cloud service, and network appliance settings before making production changes.
Exports and copied rows reflect the current model inputs and results, so avoid sharing them when source addresses, traffic rates, or destination names are sensitive.
Provider limits, cooldown timers, and retry behavior can change outside the model. Recheck assumptions after platform updates, quota changes, or architecture changes.

Worked Examples:

Linux host calling one busy API

A service uses Linux default range, 1 source address, 800 new connections per second, a 70% hottest destination share, 2 seconds of connection lifetime, and 60 seconds of reuse hold. Required hot slots is about 34,720. The default Linux range provides 28,232 physical slots before reserve, so Hard exhaustion risk is the expected status and Mitigation Ledger should point toward pooling, lower churn, more source addresses, or traffic spread.

AWS NAT with two public source addresses

An AWS NAT Gateway IPv4 scenario uses 2 source addresses and the 55,000 same-destination cap per address. With a 20% safety reserve, the planned pool is roughly 88,000 slots before reserved ports. If Required hot slots is 70,000, Planned pool use stays below 100%, but an 80% watch threshold can still show Near threshold when there is little burst room.

Reuse hold drives the result

A proxy making 400 new connections per second with a 50% hot share needs 1,000 held slots when Slot hold time is 5 seconds. With the same connection rate and a 65 second hold, Required hot slots rises to 13,000. That difference explains why keep-alive, HTTP/2, backoff, and shorter NAT cooldown assumptions can matter more than a small port-range adjustment.

Bad custom range

A custom setup with low port 60000 and high port 40000 cannot produce a valid inclusive range. The summary changes to Check port model, and Exhaustion Snapshot lists the range problem instead of showing Planned pool use and Required hot slots. Fixing the high value restores the capacity estimate and pressure curve.

FAQ:

Can one source port be reused for different destinations?

Yes. The model focuses on the hottest destination tuple because that is where repeated flows need distinct held slots. A different destination tuple can usually reuse the same source-port number independently.

What should I enter for connection lifetime?

Use the average active socket time for the hot destination. If an application keeps sockets open after a request finishes, use socket lifetime from traces, connection pool metrics, or network observations rather than request latency alone.

Why is reuse hold time separate?

A closed connection can leave its source-port slot unavailable during TCP TIME-WAIT or a NAT cooldown period. Slot hold time adds Connection lifetime and Reuse hold time because both affect the number of held slots.

Why does a provider cap matter if the port range is wider?

A managed NAT service may publish a same-destination connection cap that is lower than the raw port range. When Provider cap is positive, the model uses that smaller limit before subtracting reserved ports.

What does the Reuse Pressure Curve show?

It plots total new connections per second against Planned pool use under the current hot-share and hold-time assumptions. The current point, watch threshold, and reserve boundary show how much churn increase the pool can tolerate.

Does Within planned reserve mean SNAT exhaustion cannot happen?

No. It means the entered assumptions fit the modeled planned pool. A hotter destination, longer hold time, retry burst, lower provider quota, or unrelated network failure can still cause outbound connection errors.

Glossary:

Ephemeral port: A temporary local source port assigned automatically for an outbound connection.
Destination tuple: The destination address, destination port, and protocol receiving an outbound flow.
SNAT: Source network address translation, where private-source traffic is mapped to a translated source address and source port.
Reuse hold: The time after a connection closes before the same source port can be reused for the same destination.
Provider cap: A service-specific same-destination connection limit that can be lower than the raw port range.
Planned pool use: Required hot-destination slots divided by the source-port pool left after the safety reserve.
Physical pool use: Required hot-destination slots divided by total source-port inventory before the safety reserve is removed.

References:

Service Name and Transport Protocol Port Number Registry, IANA.
IP Sysctl, The Linux Kernel documentation.
TCP/IP port exhaustion troubleshooting, Microsoft Learn.
NAT gateway basics, Amazon Web Services.
NAT Gateway Resource, Microsoft Learn.
How to check active TCP connections in Windows, simplified.guide.