Skip to main content

cpsrvd only binds to tcp6 and not tcp4

Comments

5 comments

  • cPRex Jurassic Moderator

    Hey there!  That's definitely odd as cPanel always requires an IPv4 address to function properly.

    If you restart the cPanel service while watching the /usr/local/cpanel/logs/error_log file do you see anything helpful there?  If you run "ip a" on the system does it show the IPv4 addresses are properly bound to an interface?

    0
  • quietFinn

    AI gave this answer:
    "Dual-Stack Binding: On many Linux distributions, an IPv6 socket can natively accept both IPv6 and legacy IPv4 connections. cpsrvd is simply binding to :: (the IPv6 equivalent of 0.0.0.0) which handles all incoming traffic."

    0
  • Luke Broadbent

    The output of "/usr/local/cpanel/logs/error_log" when restarting cpsrvd:

    [2026-07-16 18:37:41 +1000]: “/scripts/restartsrv_cpsrvd ” called by (237455 - bash)
    ==> cpsrvd 11.136.0.29 started
    ==> cpsrvd: loading security policy....Done
    ==> cpsrvd: Setting up SSL support ... Done
    ==> cpsrvd: transferred port bindings: 10,11,12,18,3,4,5,6,7,8,9
    ==> cpsrvd: bound to ports
    [2026-07-16 18:38:04 +1000] info [cpsrvd] version 11.136.0.29 online

     

    The output of "ip a" includes the following:

    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
        link/ether 00:0a:f7:83:50:2c brd ff:ff:ff:ff:ff:ff
        altname eno1
        altname enp1s0f0
        inet 101.0.65.154/30 brd 101.0.65.155 scope global eth0
           valid_lft forever preferred_lft forever
        inet6 2401:fc00:0:2a::8/126 scope global 
           valid_lft forever preferred_lft forever
        inet6 2401:fc00:0:2a::4/64 scope global 
           valid_lft forever preferred_lft forever
        inet6 fe80::20a:f7ff:fe83:502c/64 scope link 
           valid_lft forever preferred_lft forever

     

    So things look like they're OK.

    It should also probably be noted that this seems to only apply to the cpsrvd service - all other aspects of the server (websites, mail, etc.) can be accessed via IPv4.

    It should also be noted that I am also trying to deal with my network provider about this issue (who don't seem to want to know about the problem), as it has only raised its head since my dedicated server provider blocked cPanel login access while fixing the cPanel login exploit issue.

    The output of "ss -tulpn | grep cpsrvd" show:

    tcp   LISTEN 0      45                 *:2082             *:*    users:(("cpsrvd (SSL",pid=3952312,fd=3))
    tcp   LISTEN 0      45                 *:2083             *:*    users:(("cpsrvd (SSL",pid=3952312,fd=5))
    tcp   LISTEN 0      45                 *:2086             *:*    users:(("cpsrvd (SSL",pid=3952312,fd=4))
    tcp   LISTEN 0      45                 *:2087             *:*    users:(("cpsrvd (SSL",pid=3952312,fd=6))
    tcp   LISTEN 0      45                 *:2095             *:*    users:(("cpsrvd (SSL",pid=3952312,fd=11))
    tcp   LISTEN 0      45                 *:2096             *:*    users:(("cpsrvd (SSL",pid=3952312,fd=12))

     

    But Apache, which will happily accept both v4 and v6 connections shows:

    tcp   LISTEN 0      511          0.0.0.0:443        0.0.0.0:*    users:(("httpd",pid=4169120,fd=6),("httpd",pid=254508,fd=6),("httpd",pid=254507,fd=6),("httpd",pid=254499,fd=6),("httpd",pid=254496,fd=6),("httpd",pid=253873,fd=6),("httpd",pid=253801,fd=6),("httpd",pid=253797,fd=6),("httpd",pid=253663,fd=6),("httpd",pid=253487,fd=6),("httpd",pid=252532,fd=6),("httpd",pid=252383,fd=6),("httpd",pid=252375,fd=6),("httpd",pid=250717,fd=6),("httpd",pid=250711,fd=6),("httpd",pid=250420,fd=6),("httpd",pid=243027,fd=6))
    tcp   LISTEN 0      511          0.0.0.0:80         0.0.0.0:*    users:(("httpd",pid=4169120,fd=3),("httpd",pid=254508,fd=3),("httpd",pid=254507,fd=3),("httpd",pid=254499,fd=3),("httpd",pid=254496,fd=3),("httpd",pid=253873,fd=3),("httpd",pid=253801,fd=3),("httpd",pid=253797,fd=3),("httpd",pid=253663,fd=3),("httpd",pid=253487,fd=3),("httpd",pid=252532,fd=3),("httpd",pid=252383,fd=3),("httpd",pid=252375,fd=3),("httpd",pid=250717,fd=3),("httpd",pid=250711,fd=3),("httpd",pid=250420,fd=3),("httpd",pid=243027,fd=3))
    tcp   LISTEN 0      511             [::]:443           [::]:*    users:(("httpd",pid=4169120,fd=7),("httpd",pid=254508,fd=7),("httpd",pid=254507,fd=7),("httpd",pid=254499,fd=7),("httpd",pid=254496,fd=7),("httpd",pid=253873,fd=7),("httpd",pid=253801,fd=7),("httpd",pid=253797,fd=7),("httpd",pid=253663,fd=7),("httpd",pid=253487,fd=7),("httpd",pid=252532,fd=7),("httpd",pid=252383,fd=7),("httpd",pid=252375,fd=7),("httpd",pid=250717,fd=7),("httpd",pid=250711,fd=7),("httpd",pid=250420,fd=7),("httpd",pid=243027,fd=7))
    tcp   LISTEN 0      511             [::]:80            [::]:*    users:(("httpd",pid=4169120,fd=4),("httpd",pid=254508,fd=4),("httpd",pid=254507,fd=4),("httpd",pid=254499,fd=4),("httpd",pid=254496,fd=4),("httpd",pid=253873,fd=4),("httpd",pid=253801,fd=4),("httpd",pid=253797,fd=4),("httpd",pid=253663,fd=4),("httpd",pid=253487,fd=4),("httpd",pid=252532,fd=4),("httpd",pid=252383,fd=4),("httpd",pid=252375,fd=4),("httpd",pid=250717,fd=4),("httpd",pid=250711,fd=4),("httpd",pid=250420,fd=4),("httpd",pid=243027,fd=4))
    0
  • cPRex Jurassic Moderator

    I would say it's best to create a ticket for this one since I don't have similar reports of this issue and this is one of those "it should just work automatically" types of things.

    0
  • Luke Broadbent

    Thanks guys.

    I'm fighting with my hosting provider to get them to recognise the issue on our dedicated server and escalate it to cPanel.

    Unfortunately I'm unable to raise a support ticket direct through cPanel yet as they provided the server and cPanel installation.

    1

Please sign in to leave a comment.