php / php/php-src

Multiple entries for PHP-FPMs listen directive

Open
#11,593 1 comment 2 reactions 1 assignee View on GitHub

@bukka is already working on this.

Since Jul 4, 2023.

Feature SAPI: fpm Status: Needs Triage
Dominant language
C
Stars
40.4k
Forks
8.1k
Avg merge
2d 13h
Merged PRs (30d)
96

Description

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:

  1. 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.

  2. 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.

  3. listen = [::1]:9000 (accessible only locally via IPv6)
    Enables local accessibility through IPv6, but it does not support IPv4 connections.

  4. 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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.