Skip to content

TCP connection lifecycle in Windows 11 25H2

On this page

Short answer

Section titled “Short answer”

These parameters control the TCP connection lifecycle: protocol extensions, TIME_WAIT, keep-alive and Path MTU problem detection. They do not set ping and do not speed up an already established connection.

What was checked

Section titled “What was checked”

We checked how tcpipreg.sys and NSI read the TCP lifecycle parameters, what the default values and ranges are, and whether the configuration updates without a reboot.

Scope of research

Section titled “Scope of research”

Windows 11 25H2 build 26200.9168, tcpipreg.sys and NSI. Controlled collection of network traces across different networks and applications was not performed.

Methodology

Section titled “Methodology”

Static analysis of system components, bootlog analysis and observation of live configuration updates.

Canonical values

Section titled “Canonical values”
Registry path Value Type Default/typical state Role
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters Tcp1323Opts REG_DWORD 3, if absent legacy extensions policy
same path TcpTimedWaitDelay REG_DWORD 120 seconds, 30..300 TIME_WAIT duration
same path KeepAliveTime REG_DWORD 7200000 ms idle keep-alive interval
same path EnablePMTUBHDetect REG_DWORD 0 PMTU black-hole detection

The legacy TCP parameters are read by tcpipreg.sys and passed through NSI to the tcpip.sys component. For some values ZwNotifyChangeKey is used, which allows the configuration to be re-read without a full restart of the network stack.

Values

Section titled “Values”

Tcp1323Opts is kept for compatibility. Its 0..3 values historically described TCP window scaling and timestamps. In Windows 11 25H2 the parameter is read by tcpipreg.sys, and the 1 value is converted before being passed to NSI. Modern automatic receive window tuning is governed by a separate policy. Therefore the old bit table does not determine the actual state of each connection.

TcpTimedWaitDelay sets how long the TCP control block is held in TIME_WAIT after the connection is closed. The documented range is 30..300 seconds, the default is 120. Shortening the wait frees temporary ports earlier, but leaves less time for protection against late segments from the old connection.

KeepAliveTime sets the interval before the keep-alive probe packet for an idle connection. By default it is 7 200 000 ms. The application must enable keep-alive for the socket separately, so reducing the global interval does not start background checks for all connections.

EnablePMTUBHDetect=1 enables Path MTU black-hole detection, when ICMP fragmentation-needed notifications do not reach the sender. The mechanism helps with such a problematic route and can increase the number of retransmissions. It does not speed up a healthy network.

Usefulness and limitations

Section titled “Usefulness and limitations”

The parameters are useful for servers and clients with a large number of short TCP connections or an unstable MTU. Universal acceleration of ordinary applications should not be expected from changing a single value. The result depends on the other side of the connection, NAT, the router, the network adapter driver, VPN and congestion control.

The research applies to Windows 11 25H2 build 26200.9168. Controlled collection of network traces across different networks and applications was not performed.

tcpipreg.sys monitors changes to the key and can update some legacy settings without a reboot. Already open TCP connections do not necessarily renegotiate their parameters. For a correct comparison of the original and changed state, create new connections.

What is confirmed

Section titled “What is confirmed”
  • Paths, types, default values and ranges of the parameters in the build studied.
  • Reading through tcpipreg.sys and NSI; some values update without a full restart of the stack.
  • For Tcp1323Opts, the 1 value is converted before being passed to NSI.
  • Keep-alive requires separate enabling for the socket.

What is not confirmed

Section titled “What is not confirmed”
  • Acceleration of applications from changing individual values.
  • Behavior in specific networks, behind NAT, VPN and under packet loss.
  • Renegotiation of parameters by already open connections.

Practical conclusion

Section titled “Practical conclusion”

Leave the default values. Change the parameters only for servers and clients with a large number of short connections or an unstable MTU, and compare the result on new connections.

Restoring the state

Section titled “Restoring the state”

Return the stock values or delete the optional entries. Check the result on new connections: already open ones may keep their previous parameters.

Sources

Section titled “Sources”

For how to reproduce the dynamic part of the observations, see How to check it yourself.

The research and the tools used belong to the BoosterX developer, so the developer has a direct interest in the results. The methodology and the limits of applicability are described above, and the conclusions can be verified against open data and the listed public sources.

Public sources checked: 2026-09-02.

Change history

Section titled “Change history”
  • 2026-09-20: added a conflict-of-interest disclaimer and a link to independent verification of the dynamic observations in the methodology.
  • 2026-09-02: first publication; readers, defaults and live reload confirmed, limits of the practical effect added.