WordPress PHP 新的安装警告 (连接超时)

问题描述

当我访问我的新 WordPress 3.4.1 安装 (挪威语) 时，我得到这个 PHP 警告。


Warning: fopen(URL_TO_MY_WORDPRESS_PAGE/wp-cron.php?doing_wp_cron=1341476616.7605190277099609375000): failed to open stream: Connection timed out in PATH_TO_MY_WP_FILES/wp-includes/class-http.php on line 923

当然，WP_DEBUG 标志设置为 true，因为它在开发服务器上运行。

这是间歇性发生的，所以它似乎是 wp-cron 的一个问题。

这可能是 WordPress 中的错误还是在我的服务器上出错？我应该担心吗

该服务器是一个新鲜的 Ubuntu Server 12.04 VM 与 LAMP 堆栈。

Google search shows I’m not the only one experiencing this.(请参阅列出的页面的缓冲/索引版本，以查看实际错误。)

编辑：我也在首页上得到同样的 PHP 警告。这可能与网络服务器正在进行 NAT 的事实有关吗？目前，我已经设置了防火墙，将开发服务器上的端口 19235 指向 80 。

最佳解决方案

答案显然是 YES，我应该担心。经过一番研究，我发现这个警告似乎与 WordPress 托管的服务器上的配置错误有关 (即我的服务器问题，而不是 WordPress) 。

常见错误配置：

服务器没有 DNS，所以它不能弄清楚”example.com” 是谁，即使它本身。
服务器管理员在安全性方面的误导性尝试中阻止了”loopback” 请求，因此它不能实际回拨自己的电话。
服务器运行的东西叫做”mod_security” 或类似的，由于 brain-dead 的配置，它主动阻止了呼叫。

我的案例中的问题实际上是由我的防火墙 (pfSense)，which has “Disable NAT reflection” by default(列为常见原因＃2) 引起的。

在服务器本身，我试图使用 telnet 到达自己，结果如下：


$ telnet external.server.hostname.com 19235
Trying XXX.XXX.XXX.XXX...
telnet: Unable to connect to remote host: Connection timed out

要解决这个问题，我不得不在我的防火墙上禁用 NAT 反射。在我的情况下，这是在 System-> Advanced-> 防火墙/NAT 下的 pfSense 的 Web 界面。资料来源：http://forum.pfsense.org/index.php?topic=3473.0

现在我可以通过防火墙连接到自己 (在服务器本身上) 很好：


$ telnet external.server.hostname.com 19235
Trying XXX.XXX.XXX.XXX...
Connected to external.server.hostname.com.
Escape character is '^]'.

我不再得到关于 wp-cron 的 PHP 警告。

在阅读了关于 wp_cron 的详细答案后，我想出了这一点，解释了它的工作原理。

Short answer: Add this to the defines in your wp-config.php file: define(‘ALTERNATE_WP_CRON’, true);

Really long answer, for masochists: Scheduled posts are not now, and have never been, “broken”. The developers of WordPress cannot fix it because there is nothing to fix.

The problem lies in the fact that your server, for some reason, cannot properly execute the wp-cron process. This process is WordPress’ timing mechanism, it handles everything from scheduled posts to sending pingbacks to XMLRPC pings, etc.

The way it works is pretty simple. Whenever a WordPress page loads, internally WordPress checks to see if it needs to fire off wp-cron (by comparing the current time with the last time wp-cron ran). If it does need to run wp-cron, then it tries to make an HTTP connection back to itself, calling the wp-cron.php file.

This connection back to itself is there for a reason. wp-cron has a lot of work to do, and that work takes time. Delaying the user seeing his webpage while it does a bunch of stuff is a bad idea, so by making that connection back to itself, it can run the wp-cron program in a separate process. Since WordPress itself doesn’t care about the result of the wp-cron, it only waits a second, then goes back to rendering the webpage for the user. Meanwhile, wp-cron, having been launched, does its work until it’s finished or it runs out of execution time.

That HTTP connection is where some badly configured systems fail. Basically, WordPress is acting like a web browser. If your site was http://example.com/blog, then WP will call http://example.com/blog/wp-cron.php to start the process. However, some servers simply can’t do that for some reason. Among the possible reasons:

Server doesn’t have DNS, and so it can’t figure out who “example.com” is, even though it is itself.

Server administrators, in a misguided attempt at security, have blocked “loopback” requests, so it can’t actually make a call back to itself.

Server is running something called “mod_security” or similar, which actively blocks the call due to brain-dead configuration.

Something else.

The point is that for whatever reason, your web server is configured in some non-standard way that is preventing WordPress from doing its job. WordPress simply can’t fix that.

However, if you have this condition, there is a workaround. Add this to the to defines in your wp-config.php file:
define('ALTERNATE_WP_CRON', true);
This alternate method uses a redirection approach, which makes the users browser get a redirect when the cron needs to run, so that they come back to the site immediately while cron continues to run in the connection they just dropped. This method is a bit iffy sometimes, which is why it’s not the default.