全新安装中的PHP警告（连接超时）

访问全新的WordPress 3.4.1安装程序（挪威语）时，出现此PHP警告。

警告：fopen（URL_TO_MY_WORDPRESS_PAGE / wp-cron.php？doing_wp_cron = 1341476616.7605190277099609375000）：无法打开流：连接超时在PATH_TO_MY_WP_FILES / wp-includes / class-http.php行923

^{当然，这是在开发服务器上运行时将WP_DEBUG标志设置true为的。}

这是间歇性发生的，因此似乎是一个问题wp-cron。

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

该服务器是带有LAMP堆栈的全新Ubuntu Server 12.04 VM。

Google搜索显示我不是唯一经历过这种情况的人。（请参阅列出的页面的缓冲/索引版本，以查看实际错误。）

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

答案显然是肯定的，我应该担心。经过研究后，我发现警告似乎与WordPress托管服务器上的配置错误有关（即，我的服务器存在问题，而不是WordPress）。

常见的错误配置：

1. 服务器没有DNS，因此即使是“ example.com”本身，也无法确定谁是谁。
2. 服务器管理员出于对安全性的错误尝试而阻​​止了“回送”请求，因此它实际上无法对其自身进行回叫。
3. 服务器正在运行名为“ mod_security”或类似内容的内容，由于配置不合理，该功能会主动阻止该呼叫。

就我而言，问题实际上是由我的防火墙（pfSense）引起的，该防火墙默认情况下具有“禁用NAT反射”功能（列为常见原因2）。

在服务器本身上，我尝试使用telnet与自己联系，结果如下：

$ telnet external.server.hostname.com 19235
正在尝试XXX.XXX.XXX.XXX ...
telnet：无法连接到远程主机：连接超时

要解决此问题，我必须取消选中“ 禁用防火墙上的NAT反射 ”。就我而言，这是在pfSense的Web界面中的System-> Advanced-> Firewall / NAT下。
^{来源：http : //forum.pfsense.org/index.php?topic=3473.0}

现在，我可以通过防火墙连接到我自己（在服务器上）了：

$ telnet external.server.hostname.com 19235
正在尝试XXX.XXX.XXX.XXX ...
已连接至external.server.hostname.com。
转义字符为'^]'。

而且我不再收到有关wp-cron的PHP警告。

在阅读了有关的详细答案后，我才知道了这一点wp_cron，并解释了它的工作原理。

简短答案：将其添加到wp-config.php文件中的定义中：define（'ALTERNATE_WP_CRON'，true）;

对于受虐狂来说，答案很长：预定的职位现在还没有，而且从未被“破坏”。WordPress的开发人员无法修复它，因为没有要修复的东西。

问题在于您的服务器由于某种原因无法正确执行wp-cron进程。此过程是WordPress的计时机制，它处理从计划的帖子到将pingback发送到XMLRPC ping等的所有过程。

它的工作方式非常简单。每当加载WordPress页面时，WordPress内部都会检查是否需要启动wp-cron（通过比较当前时间和上次运行wp-cron的时间）。如果确实需要运行wp-cron，则它将尝试建立与自身的HTTP连接，并调用wp-cron.php文件。

这种连接回到自身是有原因的。wp-cron有很多工作要做，而且这需要时间。在用户执行大量操作时延迟用户查看其网页是一个坏主意，因此通过使该连接返回自身，它可以在单独的进程中运行wp-cron程序。由于WordPress本身并不关心wp-cron的结果，因此它仅等待一秒钟，然后返回为用户呈现网页。同时，已启动的wp-cron会一直工作到完成或执行时间用完为止。

该HTTP连接是一些配置错误的系统失败的地方。基本上，WordPress的行为就像网络浏览器。如果您的网站是 http://example.com/blog，那么WP将调用 http://example.com/blog/wp-cron.php来启动该过程。但是，由于某些原因，某些服务器根本无法做到这一点。可能的原因包括：

1. 服务器没有DNS，因此即使它本身本身也不知道“ example.com”是谁。
2. 服务器管理员出于对安全性的错误尝试而阻​​止了“回送”请求，因此它实际上无法对其自身进行回叫。
3. 服务器正在运行名为“ mod_security”或类似内容的内容，由于配置不合理，该功能会主动阻止该呼叫。
4. 还有别的

关键是无论出于何种原因，您的Web服务器都以某种非标准的方式进行配置，从而阻止了WordPress的工作。WordPress根本无法解决此问题。

但是，如果您有这种情况，有一个解决方法。将其添加到wp-config.php文件中的to定义中：

define（'ALTERNATE_WP_CRON'，true）;

此替代方法使用重定向方法，该方法使用户浏览器在cron需要运行时获得重定向，以便当cron在刚刚断开的连接中继续运行时，他们可以立即返回站点。有时，此方法有点麻烦，这就是为什么它不是默认方法的原因。

^{资料来源：http : //wordpress.org/support/topic/scheduled-posts-still-not-working-in-282#post-1175405}

如这篇出色而详尽的文章所述，如果您无法控制服务器配置或环境（如果适用），则应采取一种解决方法

define（'ALTERNATE_WP_CRON'，true）;

在您的wp-config.php文件中。