没有一种方法可以保证有效。

PHP 的工作方式是 HTTP 服务器接收 HTTP 请求，识别它是 PHP 并将请求中继到 PHP 模块。这可以是内置在 Web 服务器中的模块，也可以是专用的“PHP 服务器”。服务器然后检查哪些 PHP 代码将使用哪些参数执行，然后执行它，生成结果并将结果中继回 HTTP 服务器，HTTP 服务器将其作为 HTTP 响应返回。

这个过程是否发生，或者接收到的结果是否来自静态页面或任何数量的过程，对于用户来说是未知的。

然而...

PHP 可以通过多种方式“揭示”自身。第一个也是最明显的是X-Powered-ByHTTP 响应标头。PHP 喜欢为自己做广告，因此在某些安装中，X-Powered-By设置了标头，其中包括该站点正在运行 PHP 以及哪个版本。

PHP中还有一个很奇怪的“复活节彩蛋”，当发送特定的查询字符串时，它会返回特定的信息，例如开发团队的学分或 PHP 徽标。可以在配置中禁用此行为，因此也不是万无一失的。如果它有效，那么它极有可能是 PHP 安装，但如果它没有，你不能完全推断它不是PHP 安装。毕竟，没有证据并不是没有证据。

堆栈跟踪和其他 PHP 错误，例如取自这个问题的美丽杰作，也可以作为指示：

当然，所有这些方法都只是因为一些错误配置才有效。在正确配置的服务器上，无法确定是否使用了 PHP。

因为 PHP 是由自己的代码构建的

也许通过查看它如何解析特定的查询字符串（例如?a[]=1&a[]=2&a[]=3）、它支持哪种正则表达式语法、它产生的 HTTP 响应标头的独特排列、PHP 函数、扩展和依赖项产生的结果的独特字节级特征（例如它发送的字节的顺序和结构mail()），RFC 不关心的特定于实现的东西，测量处理一些将调用特定 PHP 函数的特定请求所花费的时间，使用它自己的漏洞，或者通过任何低级怪癖它可能有独特的可能标识 PHP。

不要假设攻击者永远不会知道您正在使用 PHP。无论配置如何正确，一定有一些你不知道但老练的攻击者的怪癖。您不能配置PHP 引擎的内部行为。

从实际的角度来看，你的问题并不重要。

如果您知道您的服务器运行的是易受攻击的 PHP 版本或其他任何东西，则需要对其进行修补，而不是隐藏。

同时，攻击者往往只是在没有事先发现的情况下运行各种自动化请求：打开任何一个公共 Web 服务器的日志，你会发现 phpmyadmin 和其他知名工具的管理页面的 404 错误，即使服务器是 100% ASP.NET

在某些（但不是全部）情况下 - 如果站点使用 PHP，您可能会在响应标头中看到这一点。查看响应标头的一种方法是使用curl该-I选项。

例如：

curl -I www.example.com

server如果站点使用的是 PHP，您可能会在响应标头中看到如下内容：

Apache/2.4.25 (Debian) PHP/7.0.19-1 OpenSSL/1.0.2l