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.