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 }}

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Ephemeral port exhaustion happens when a host, proxy, or NAT gateway runs out of temporary source ports for new outbound connections. The failure often appears as intermittent connection timeouts, refused client sockets, or NAT errors even though the destination service is still healthy. It matters most when one busy application opens many short-lived connections to the same destination IP, destination port, and protocol.

A source port is not consumed globally in the same way for every possible connection. The same source port can usually be used at the same time for different destination endpoints, but a connection to the same destination tuple needs a distinct source port while the socket is active and during any reuse delay after close. That is why one hot API endpoint, database endpoint, proxy target, or third-party service can become the limiting case before the total connection count looks alarming.

Outbound capacity planning should combine connection rate with hold time. A workload creating 500 new connections per second with a 60 second reuse hold can require tens of thousands of source-port slots for one destination, even when individual requests finish quickly. Connection pooling, keep-alive, HTTP/2, more source addresses, wider port ranges, or better traffic distribution can all change the result, but only if they reduce the hot-destination source-port pressure.

Diagram showing source IP port pools feeding a hot destination, held slots, and a planned pool with reserve and exhaustion markers.

The estimate is still a planning model. It does not inspect live kernel socket tables, cloud metrics, firewall state, DNS behavior, or remote service limits. Use it to size the source-port pool, compare mitigation options, and decide where to look next when outbound failures cluster around one destination.

Technical Details:

A TCP or UDP outbound flow is distinguished by a 5-tuple: source address, source port, destination address, destination port, and protocol. For source-port exhaustion, the tightest constraint is usually the repeated use of one source address pool against one destination tuple. Ports that are unavailable because they are active, in TCP TIME-WAIT, or in a NAT cooldown period cannot immediately serve another connection to that same destination.

Operating systems and managed NAT services use different starting assumptions. IANA defines dynamic and private ports as 49152 through 65535. Linux commonly exposes ip_local_port_range with default values 32768 and 60999, while modern Windows uses 49152 through 65535 for dynamic client ports. Managed NAT services may use a wide local range internally but still publish same-destination connection limits, such as 55,000 per IPv4 address for AWS NAT Gateway and 50,000 per public IP address for Azure NAT Gateway.

The model treats the port range as inclusive, subtracts reserved ports from each source address, applies a provider cap when present, multiplies by the number of source addresses, and then removes the safety reserve. Required slots are driven by the hottest destination because distributing calls across several destination tuples lets the same source-port numbers be reused independently for each tuple.

Formula Core:

The main calculation converts a connection churn rate into the number of source-port slots that must be available for the busiest destination.

\begin{array}{lll} P_{range} & = & P_{high} - P_{low} + 1 \\ P_{limit} & = & P_{range} when provider cap is 0; otherwise min (P_{range}, P_{cap}) \\ P_{source} & = & max (0, P_{limit} - P_{reserved}) \\ P_{planned} & = & P_{source} \times S \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}

Variables used in the ephemeral port exhaustion formula
Symbol	Meaning	Unit
`C`	Total new outbound connections per second.	conn/s
`H`	Share of total churn going to the busiest destination tuple, entered as a fraction.	ratio
`S`	Source addresses or NAT public addresses sharing the modeled workload.	addresses
`R`	Safety reserve removed from the physical source-port pool before planned capacity is judged.	ratio
`P_cap`	Optional provider same-destination cap per source address; when set to `0`, the selected port range is used.	slots/source

Status Rules:

Ephemeral port pressure status rules
Status	Boundary	Meaning
`Needs input`	Invalid port range or zero usable planned pool.	The capacity math should not be used until the input issue is fixed.
`Port pool can fill`	`Physical pool use >= 100%`.	The modeled hot destination can consume the entire source-port inventory.
`No reserve left`	`Planned pool use >= 100%` while physical pool use stays below `100%`.	The workload fits only by consuming the reserve intended for bursts and measurement error.
`Near threshold`	`Planned pool use >= Watch threshold`, where the threshold can be set from `40%` to `100%`.	The modeled workload remains below reserve exhaustion but is close enough to watch.
`Within planned reserve`	Planned pool use is below the watch threshold.	The entered assumptions leave planned headroom for the hot destination.

Modeled Bounds:

Input bounds for the ephemeral port exhaustion model
Input	Accepted model range	Effect on capacity
`Source addresses`	Whole number from `1` to `512`.	Multiplies the same-destination port inventory.
`Ephemeral port range`	Inclusive low and high values from `1` to `65535`; high must be at least low.	Sets raw ports per source before reserves and provider caps.
`New connections`	Non-negative connection rate.	Raises required slots in direct proportion to churn.
`Hottest destination share`	`0.1%` to `100%`.	Concentrates total churn onto the destination that controls exhaustion risk.
`Connection lifetime` and `Reuse hold time`	Non-negative seconds.	Together define how long each hot-destination source-port slot stays unavailable.
`Reserved ports`, `Safety reserve`, and `Provider cap`	Reserved ports are non-negative; safety reserve is `0%` to `80%`; provider cap can be `0` or a positive slot limit.	Reduce the pool used for planned capacity and same-destination limits.

Everyday Use & Decision Guide:

Begin with the platform preset that most closely matches the source of outbound traffic. Linux default range is a useful host starting point, IANA / Windows modern range matches the 49152 through 65535 dynamic range, and the AWS and Azure NAT presets load the provider same-destination caps used by the model. Switch to Custom when sysctl, netsh, firewall policy, or NAT configuration differs from those defaults.

Use peak values, not daily averages. Enter the bursty connection rate in New connections, then set Hottest destination share to the busiest single destination tuple. If a service sends 1,000 connections per second across ten APIs but one API receives 600 of them, the hot share is 60%, not 10%.

Use Source addresses for the number of local source IPs, NAT public IPs, or gateway addresses that share this exact outbound workload.
Set Connection lifetime from observed socket duration for the hot destination. Request latency alone can be too low when clients keep sockets open.
Set Reuse hold time from TCP TIME-WAIT, NAT cooldown, or provider behavior. A short request followed by a long hold still occupies planning capacity.
Use Reserved ports only for exclusions that actually reduce the selected source-port range.
Keep a Safety reserve when retries, rolling deploys, DNS shifts, or load-test noise can create bursts above the measured rate.

The useful first read is the summary percentage and badges, then the Exhaustion Snapshot. If Required hot slots is close to or above Planned usable slots, reducing average traffic across all destinations may not fix the issue. The more direct fixes are to reduce hot-destination churn, lower hold time through connection reuse, add source addresses, widen the usable range, or split the destination tuple.

Do not treat a green result as proof that outbound networking is healthy. It means the entered source-port model has headroom. Before changing production limits, compare Connection-rate headroom, Physical pool use, and recent platform metrics or socket-state samples for the same source and destination.

Step-by-Step Guide:

Build the model from the source-port pool first, then add the connection churn that consumes it.

Choose Platform preset. Confirm that Ephemeral port range, Reuse hold time, and Provider cap match the host or NAT platform you want to model.
Enter Source addresses. The badge beside the summary should reflect the number of source IPs that multiply the port inventory.
Check Ephemeral port range. If the high value is lower than the low value, the page shows Check port model and an input issue instead of capacity results.
Enter peak New connections, then move Hottest destination share until it represents the busiest destination tuple. Watch Required hot slots in Exhaustion Snapshot.
Set Connection lifetime and Reuse hold time. The Slot hold time row in Port Budget should match the active plus reuse-hold seconds you intended.
Open Advanced if you need Destination endpoints, Reserved ports, Safety reserve, Provider cap, Watch threshold, or Decimal precision.
Read Pressure status, Planned pool use, Physical pool use, and Max total rate before reserve. Those fields decide whether the modeled workload is comfortable, near the watch threshold, reserve-exhausted, or hard-exhausted.
Use Mitigation Ledger and Reuse Pressure Curve to compare fixes before changing the source address count, client pooling, destination distribution, or OS/NAT port policy.

Interpreting Results:

Planned pool use is the headline percentage because it compares required hot-destination slots against the pool left after the safety reserve. Physical pool use is the harder ceiling. Once physical use reaches 100%, the model is saying the entered workload can consume all available same-destination source-port inventory.

How to interpret ephemeral port pressure outputs
Output cue	What it means	Follow-up check
`Within planned reserve`	Required hot slots are below the configured watch threshold.	Confirm that peak churn and hot share came from the same time window.
`Near threshold`	Planned use is at or above the watch threshold but below reserve exhaustion.	Inspect retry spikes and connection pooling before traffic grows.
`No reserve left`	The workload fits only by spending the safety reserve.	Use `Mitigation Ledger` to test added source addresses, lower hold time, or lower total churn.
`Port pool can fill`	Physical pool use is at least `100%`.	Treat this as a source-port capacity risk and compare against socket or NAT metrics for that destination.

Connection-rate headroom tells you how much total churn can rise or must fall before the planned reserve boundary, assuming the hot-destination share stays unchanged. If the hot share is wrong, the headroom is wrong too. A small increase in concentration toward one destination can be more important than a larger increase in evenly distributed traffic.

A passing result does not mean the remote service, DNS path, firewall, route, or application pool is healthy. It only says the entered port inventory and hold-time assumptions leave capacity. Verify the result with platform counters such as SNAT usage, connection failures, socket states, or NAT gateway metrics before using it as a production gate.

Worked Examples:

Linux host hitting one hot API:

With Linux default range, one Source address, 800 conn/s, 70% hottest destination share, 2 sec connection lifetime, 60 sec reuse hold, and a 20% safety reserve, the model needs about 34,720 hot-destination slots. Planned pool use is about 153.7% and Physical pool use is about 123.0%, so Pressure status becomes Port pool can fill. The mitigation table shows that adding one source address would bring the same assumptions back below the planned boundary.

AWS NAT Gateway with two source addresses:

An AWS NAT Gateway preset with 2 source addresses, 2,000 conn/s, 50% hot share, 2 sec connection lifetime, 60 sec reuse hold, and a 20% safety reserve models 55,000 effective same-destination slots per source. Required hot slots are about 62,000, planned usable slots are about 88,000, and Planned pool use is about 70.5%. Connection-rate headroom is roughly 839 conn/s before reserve at the same hot share.

Azure NAT Gateway with a concentrated destination:

With the Azure preset, one public IP, 1,000 conn/s, 90% hot share, 5 sec connection lifetime, and 65 sec reuse hold, required hot slots reach about 63,000. The provider cap leaves 50,000 physical slots before reserve, so Planned pool use is about 157.5% and Physical pool use is about 126.0%. Adding another public IP or cutting the hot share materially changes the result because both actions expand or relieve the same-destination slot pressure.

Custom range entered backward:

A custom model with Ephemeral port range set from 60000 through 50000 cannot produce a valid pool. The summary changes to Check port model, and Exhaustion Snapshot reports that the port range high must be greater than or equal to the low value. Fixing the range restores the capacity rows and chart.

FAQ:

Can the same source port be reused for different destinations?

Yes. The model focuses on the busiest destination tuple because the same source-port number can usually be reused for another destination tuple, while repeated connections to the same destination need separate held slots.

What should I enter for connection lifetime?

Use the average active socket time for the hot destination, not only application request latency. A client that keeps sockets open for pooling should use the socket lifetime visible in metrics or traces.

Why is reuse hold time separate from connection lifetime?

A closed connection can keep its source-port slot unavailable for the same destination during TCP TIME-WAIT or a NAT cooldown. Slot hold time adds Connection lifetime and Reuse hold time because both affect required slots.

Why does the provider cap override part of a wide port range?

Managed NAT services can publish same-destination connection caps that are lower than the raw port numbers available. When Provider cap is positive, the model uses the smaller of the selected port range and that cap before subtracting reserved ports.

Does a green status prove that SNAT exhaustion cannot happen?

No. Within planned reserve means the entered assumptions fit the modeled source-port pool. Bad hot-share estimates, longer reuse holds, retry storms, per-service quotas, or unrelated network failures can still cause outbound errors.

Where does the calculation run?

The arithmetic runs in the browser and does not need a backend lookup for the port model. Saved or shared JSON, CSV, DOCX, and chart outputs can still contain the connection rates, source counts, and platform assumptions you entered.

Glossary:

Ephemeral port: A temporary local source port assigned for an outbound connection.
Destination tuple: The destination IP address, destination port, and protocol that receive the outbound connection.
Source address: The local host IP, NAT public IP, or gateway address that supplies source-port inventory.
SNAT: Source network address translation, where outbound private-source traffic is mapped to a public source address and port.
Reuse hold: The time after a connection closes before the same source port can be reused for the same destination.
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 the 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.
The default dynamic port range for TCP/IP has changed, Microsoft Learn.
NAT gateway basics, Amazon Web Services.
Azure NAT Gateway resource, Microsoft Learn, last updated April 30, 2026.
RFC 9293: Transmission Control Protocol (TCP), IETF, August 2022.