Description
Currently, PHP-FPM provides limited options for defining the host address, restricting it to either no host, an IPv4 address, or an IPv6 address. Here are the existing configurations and their limitations:
-
listen = 9000 (IPv4 and IPv6, but accessible from all sources)
This configuration allows PHP-FPM to listen on both IPv4 and IPv6 addresses, but it lacks the ability to specify a particular host.
-
listen = 127.0.0.1:9000 (accessible only locally via IPv4)
PHP-FPM can be accessed locally using IPv4, but it does not support IPv6 connections.
-
listen = [::1]:9000 (accessible only locally via IPv6)
Enables local accessibility through IPv6, but it does not support IPv4 connections.
-
listen = localhost:9000 (binds to IPv4 only)
This configuration restricts PHP-FPM to bind exclusively to IPv4 in my case.
The current limitations force users to make compromises. One possible solution is to globally set PHP-FPM to listen on port 9000 and control access through firewall rules or the listen.allowed_clients directive. However, it is desirable to have firewall-independent configurations and ensure closed internet access.
To address this, I propose introducing support for multiple interfaces in the PHP-FPM configuration:
listen = 127.0.0.1:9000, [::1]:9000
This configuration would allow PHP-FPM to listen on both IPv4 (127.0.0.1) and IPv6 ([::1]) addresses simultaneously, providing full control over the interfaces while maintaining full backwards-compatibility.
Alternatively, another solution could involve introducing a "port" directive and making the port specification optional within the listen directive:
listen = 127.0.0.1, [::1]
port = 9000
By implementing either of these solutions, clients can choose the most suitable approach based on their requirements and preferences.
This enhancement would also allow system administrators - particularly nginx upstream users with split configurations - to use "localhost" as a reliable target and leave it up to nginx/dns resolver/system settings to determine the IP version instead of "hard-coding" it into dozens - if not hundred - of files.
Please kindly consider my request.
Description
Currently, PHP-FPM provides limited options for defining the host address, restricting it to either no host, an IPv4 address, or an IPv6 address. Here are the existing configurations and their limitations:
listen = 9000 (IPv4 and IPv6, but accessible from all sources)
This configuration allows PHP-FPM to listen on both IPv4 and IPv6 addresses, but it lacks the ability to specify a particular host.
listen = 127.0.0.1:9000 (accessible only locally via IPv4)
PHP-FPM can be accessed locally using IPv4, but it does not support IPv6 connections.
listen = [::1]:9000 (accessible only locally via IPv6)
Enables local accessibility through IPv6, but it does not support IPv4 connections.
listen = localhost:9000 (binds to IPv4 only)
This configuration restricts PHP-FPM to bind exclusively to IPv4 in my case.
The current limitations force users to make compromises. One possible solution is to globally set PHP-FPM to listen on port 9000 and control access through firewall rules or the listen.allowed_clients directive. However, it is desirable to have firewall-independent configurations and ensure closed internet access.
To address this, I propose introducing support for multiple interfaces in the PHP-FPM configuration:
listen = 127.0.0.1:9000, [::1]:9000
This configuration would allow PHP-FPM to listen on both IPv4 (127.0.0.1) and IPv6 ([::1]) addresses simultaneously, providing full control over the interfaces while maintaining full backwards-compatibility.
Alternatively, another solution could involve introducing a "port" directive and making the port specification optional within the listen directive:
listen = 127.0.0.1, [::1]
port = 9000
By implementing either of these solutions, clients can choose the most suitable approach based on their requirements and preferences.
This enhancement would also allow system administrators - particularly nginx upstream users with split configurations - to use "localhost" as a reliable target and leave it up to nginx/dns resolver/system settings to determine the IP version instead of "hard-coding" it into dozens - if not hundred - of files.
Please kindly consider my request.