Ephemeral Port Exhaustion Calculator

{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }}{{ badge.value }}

SourcesPort windowHot tuple

Platform preset:

Choose the closest source-port allocator, then override the visible values when your host or gateway differs.

Source addresses:

Count the local source IPs, NAT public IPs, or gateway addresses that actually share this workload.

addresses

Ephemeral port range:

Enter the inclusive low and high port numbers reported by the host or platform.

Same-destination cap:

AWS and Azure presets load their documented per-address same-destination limits; use 0 for range-only host math.

slots/address

New connections:

Use measured peak connection churn, not requests per second when connections are pooled or multiplexed.

conn/s

Hot destination share: {{ formatPercent(hottest_destination_share_pct, 1) }}

Concentration matters because a source port can be reused concurrently for different destinations but not the same tuple.

Connection lifetime:

Long-lived connections occupy their source ports before any reuse hold begins.

seconds

Reuse hold:

Confirm the transport and close path; Azure, for example, documents different timers for FIN, RST, and half-open flows.

seconds

Planning reserve: {{ formatPercent(safety_reserve_pct, 0) }}

The physical ceiling remains visible separately; use the planned pool for operating decisions.

Check assumptions. {{ workflowFeedback }}

Reserved ports:

Zero is neutral. Enter only exclusions that overlap the selected ephemeral range.

ports/address

Destination endpoints:

This adds comparison context; hottest-destination share remains the controlling pressure input.

tuples

Watch threshold: {{ formatPercent(alert_threshold_pct, 0) }}

Use 80% unless your burst profile or monitoring policy requires earlier review.

Measure	Value	Planning meaning	Copy
{{ row.metric }}	{{ row.value }}	{{ row.note }}

Move	Target	Why it helps	Copy
{{ row.metric }}	{{ row.value }}	{{ row.note }}

{{ formulaText }}

Source-port shortages often appear as intermittent outbound connection failures while CPU, bandwidth, DNS, and the remote service still look normal. Each new flow needs a source address and temporary source port, and that choice can remain occupied while the connection is active and during a post-close reuse delay.

The scarce capacity is tied to a destination tuple: destination address, destination port, and protocol. A source port may be reused at the same time for different destinations, but repeated flows from one source address to one busy destination need distinct available ports. Network address translation can concentrate thousands of private clients behind only a few public source addresses.

Factors that change ephemeral port capacity and demand
Raises available inventory	Raises occupied inventory	Often mismeasured as
More source addresses	More new connections per second	Requests per second
Wider usable port range	Higher share sent to one destination tuple	Average traffic across all services
Lower provider cap or reservation loss avoided	Longer active lifetime and reuse hold	Application response time alone

Connection churn is the rate of newly opened connections, not the number of requests. Pooling, keep-alive, and multiplexed protocols can serve many requests over a small set of flows. Retry storms do the opposite: they can multiply new connections precisely when the destination is slow or unavailable.

A planning reserve holds back part of the physical pool for bursts, timer variation, and measurement error. Crossing that reserve is an operating warning, while reaching the physical pool means the modeled hot destination needs as many or more slots than the source inventory can provide.

Platform defaults are starting assumptions rather than permanent facts. Host port ranges, reserved ports, NAT limits, close behavior, and reuse timers vary by operating system, provider, protocol, and live configuration. Measurements from the source hosts or gateways should replace presets before a production decision.

A capacity model can show that port pressure is plausible, but it cannot diagnose an incident by itself. Socket tables, NAT metrics, flow logs, connection errors, retry rates, and destination distribution are needed to confirm the cause.

How to Use This Tool:

Model the busiest destination tuple during a peak connection-churn window, using the source addresses that actually share its outbound traffic.

Choose Platform preset, then verify the loaded port range, reuse hold, and any same-destination cap against the live host or gateway.
Enter Source addresses as the local or translated addresses contributing independent port inventory to the workload.
Set the inclusive Ephemeral port range and Reserved ports. The highest port must not be lower than the lowest, and at least one usable port must remain per address.
Enter measured peak New connections and the Hottest destination share. Use connection creation, not request throughput.
Add average Connection lifetime, post-close Reuse hold, and a planning reserve that reflects burst and measurement uncertainty.
Read Capacity ledger for the current pressure status and use Mitigation plan to compare source count, hot-share, and hold-time targets.

Interpreting Results:

Planned utilization compares required hot-destination slots with the pool left after reserve. Physical utilization compares the same demand with the hard modeled inventory before reserve.

Ephemeral port pressure status boundaries
Status	Exact condition	Meaning
Within plan	Planned utilization < watch threshold	Modeled demand remains inside the selected reserve and watch level.
Watch	Planned utilization ≥ watch threshold and < 100%	Headroom remains, but the selected warning point has been crossed.
Reserve exhausted	Planned utilization ≥ 100% and physical utilization < 100%	The workload fits only by consuming the held reserve.
Physical exhaustion	Physical utilization ≥ 100%	Modeled demand meets or exceeds the physical source-port inventory.

Connection-rate headroom is positive below the planned ceiling and negative above it. Additional sources for plan rounds up to whole source addresses. Targets for hot share and reuse hold show the maximum values that would bring the current churn back within the planned pool.

Do not accept a comfortable percentage until hot-destination share and hold time are measured under stress. Averages can hide short retry bursts or one destination that dominates connection creation.

Technical Details:

The model treats each usable source port on each source address as one same-destination slot. A provider cap can reduce the raw inclusive range, reserved ports are then removed, and the planning reserve reduces the remaining physical inventory.

Formula Core:

Demand equals the hot connection rate multiplied by the total time each slot stays unavailable.

\begin{array}{lcl} R & = & p_{high} - p_{low} + 1 \\ P_{source} & = & \min (R, C) - X \\ P_{planned} & = & P_{source} \times S \times (1 - \frac{q}{100}) \\ D & = & λ \times \frac{h}{100} \times (t + u) \\ U & = & \frac{D}{P_{planned}} \times 100 % \end{array}

R is inclusive range size, C is a positive provider cap or the full range when no cap applies, X is reserved ports per source, S is source addresses, q is reserve percent, λ is total new connections per second, h is hottest-destination share, t is active lifetime, and u is reuse hold. D is required slots and U is planned utilization.

Lookup Core:

Presets load a documented starting point. Every value remains editable because live configurations and provider behavior can differ.

Ephemeral port platform preset values
Preset	Port range	Reuse hold	Same-destination cap per source
Linux default	32768 to 60999	60 s	Range only
IANA / modern Windows	49152 to 65535	240 s	Range only
AWS NAT Gateway	1024 to 65535	60 s	55,000
Azure NAT Gateway	1024 to 65535	65 s	50,000 planning cap

Rule Core:

The raw range is inclusive. A positive provider cap uses the smaller of the cap and range; zero means range-only math. Reserved ports must leave at least one port per source, and active lifetime plus reuse hold must be greater than zero. Physical exhaustion is tested first, so exactly 100% physical utilization receives the physical-exhaustion status.

The average-per-destination value is total churn divided by destination count, but it does not control capacity. Required slots always use the hottest-destination share because concentration is the limiting case.

Worked Example:

Exact physical boundary

One source address with ports 50000 through 50099 has 100 physical slots. At 10 new connections per second, 100% hot share, 1 second active lifetime, and 9 seconds of reuse hold, demand is 100 slots. A 20% reserve leaves 80 planned slots, so planned utilization is 125% and physical utilization is exactly 100%. The status is physical exhaustion. Adding a second identical source creates 200 physical and 160 planned slots, reducing planned utilization to 62.5%.

Accuracy Notes:

Use peak connection creation and the busiest destination tuple; long-window averages can understate bursts.
Confirm port ranges, reservations, provider caps, close paths, and reuse timers from live configuration and current vendor documentation.
The occupancy estimate does not model allocator collisions, every protocol state, firewall tables, packet limits, bandwidth, CPU, DNS, or remote-service capacity.
Validate the conclusion with host socket data, NAT allocation errors, flow logs, and retry metrics before changing production networking.

References:

Service Name and Transport Protocol Port Number Registry, Internet Assigned Numbers Authority.
IP Sysctl, 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.