Skip to main content
R
RockerNJ
Inspiring
June 9, 2025
Answered

Too many established TCP ports

  • June 9, 2025
  • 1 reply
  • 5220 views

I have a server running 7 instances of CF (6 sites plus root instance).  If I run a NetStat, I generally see about 1800 ports as "ESTABLISHED"  (see below for a sample).  Why so many ports connected to itself?

 

Ultimately what happens is the server just kind of dies because it can't establish any more sockets.  I don't think it's "port exhaustion" because I see the total number of connections staying around that 1800 mark, and there aren't piles of TIME_WAIT entries.

 

What I THINK is happening, is, as this issue is cycling through ports, it gets to a 65535 ceiling and is not looping back to lower ports, thus killing connectivity.

 

Any thoughts on what's going on here?

 

TCP 127.0.0.1:49890 site01-wf:49891 ESTABLISHED
TCP 127.0.0.1:49891 site01-wf:49890 ESTABLISHED
TCP 127.0.0.1:49892 site01-wf:49893 ESTABLISHED
TCP 127.0.0.1:49893 site01-wf:49892 ESTABLISHED
TCP 127.0.0.1:49894 site01-wf:49895 ESTABLISHED
TCP 127.0.0.1:49895 site01-wf:49894 ESTABLISHED
TCP 127.0.0.1:49896 site01-wf:49897 ESTABLISHED
TCP 127.0.0.1:49897 site01-wf:49896 ESTABLISHED
TCP 127.0.0.1:49898 site01-wf:49899 ESTABLISHED
TCP 127.0.0.1:49899 site01-wf:49898 ESTABLISHED
TCP 127.0.0.1:49900 site01-wf:49901 ESTABLISHED
TCP 127.0.0.1:49901 site01-wf:49900 ESTABLISHED

    Correct answer RockerNJ

    Very interesting to hear. Looking forward to further news as it becomes available. 


    Just a followup for you guys since you've all been awesome with helping.  Updating these settings seems to have fixed the problem (at least so far).  No crashes since making the update!

     

    netsh int ipv4 set dynamicport tcp start=32767 num=32768

    netsh int ipv6 set dynamicport tcp start=32767 num=32768

     

    and a registry edit:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

    TcpTimedWaitDelay

    REG_DWORD

    Value: 30

    1 reply

    BKBK
    Community Expert
    BKBKCommunity Expert
    Community Expert
    June 10, 2025

    First of all, what is your:

    • Operating System?
    • ColdFusion version and update level?
    R
    RockerNJAuthor
    Inspiring
    June 10, 2025

    Windows Server 2022 Datacenter

    Coldfusion 2021 + Hotfix20

    R
    RockerNJAuthor
    Inspiring
    June 13, 2025

    @RockerNJ , Did you try out my last suggestions? Did they help?

    Here are yet more thoughts on the issue. 

     

    You and Dave supposed that, if the traffic isn’t over 80 or 443, then these are unlikely to be HTTP requests. However, when I looked further into the issue, I found that internal HTTP communication within ColdFusion may use high-numbered dynamic ports.

    So, here are 3 reasons why It is still likely the issue is caused by HTTP/CFHTTP connections:

     

    1.  ColdFusion and the underlying (Tomcat/Jetty) servlet container may use ports different from 80 and 443.
    Since you are running multiple CF instances, each one may be configured to listen on its own custom random ephemeral port. So a cfhttp call from one CF instance to another will be using these random ports.

     

    2.  The Netstat result shows that the TCP socket pairs are bidirectional (A <==> B) and ESTABLISHED.
    The pattern:

    TCP 127.0.0.1:51140 127.0.0.1:51139 ESTABLISHED
TCP 127.0.0.1:51139 127.0.0.1:51140 ESTABLISHED

    is neither a one-way connection nor a connection from a background protocol such as RMI. It is bidirectional, exactly what you would expect from an internal client/server TCP pair. This strongly suggests application-level communication, hence HTTP.

     

    3.  ColdFusion itself (coldfusion.exe) is the process opening both ends.
    This tells us that ColdFusion is both the client and the server. This is exactly how an internal cfhttp call to 127.0.0.1:{port_number} works: one thread binds a client socket, another listens on the HTTP server socket.

     

     


    The "ColdFusion and the underlying (Tomcat/Jetty) servlet container may use ports different from 80 and 443." really does make the story make sense.  As stated earlier, we are running a scheduled task (on each of the 6 instances) every 30 seconds.  That task then does in fact make a cfhttp call to yet another module.  It certainly does explain the AMOUNT of sockets.  I'm just curious as to why they remain established.  The whole routing that the scheduled task is calling returns immediately (not some long running process).

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices