小编Mac*_*ity的帖子

我正在建立一个网站并为该网站的域购买了 SSL 证书。当我问托管公司为什么https://www.example.com拒绝连接时，他们回答说 SSL 访问是在端口 41696 上配置的。当然，https://www.example.com:41696按照他们的承诺工作，但这真的不是我想用于面向客户的网站的 URL。

托管公司还表示，即使我们获得不同的套餐，他们也无法将其更改为 443。我从未从与我合作过的任何其他托管服务提供商那里听说过。他们是否有充分的理由不让这种情况发生？或者我可以在服务器上更改任何配置以使其接受端口 443 上的 HTTPS 请求？

有没有办法在apache中产生相同的Nginx 444错误。

nginx

444--> 连接关闭，没有响应。

我喜欢这个错误，因为如果有人尝试 CURL，他会得到一个空的响应，但在 Apache 中并非如此。

我遇到了一个有趣的问题。我们有一个 PHP 脚本可以联系 LTL 托运人 ( https://facts.dohrn.com/ )。该脚本一直失败，因为它无法验证 SSL 证书。我访问了该站点，发现他们使用的是 GoDaddy SHA2 证书（使用GoDaddy 证书捆绑包 - G2，这是用于 SHA2 的）。

我安装了最新版本，ca-certificate看起来他们有Go Daddy Root Certificate Authority - G2但这不是一回事，并且在所有形式的验证中都失败了。我终于能够通过复制包并直接在 CURL 请求中使用它来让它工作。但这只是一种解决方法。是否还有其他我遗漏的东西可以在不直接安装 CA 的情况下完成这项工作？

# openssl s_client -connect fact.dohrn.com:443
CONNECTED(00000003) depth=0 OU = Domain Control Validated, CN = fact.dohrn.com verify
error:num=20:unable to get local issuer certificate verify return:1
depth =0 OU = 域控制验证，CN = fact.dohrn.com 验证
错误：num=27：证书不可信验证返回：1 深度=0 OU =
域控制验证，CN = fact.dohrn.com 验证
错误：num= 21:unable to verify the …

我已经使用以下命令设置了 cron 作业

crontab -e

似乎如果 cron 作业计划在同一天运行（即计算机尚未重新启动），那么 cron 作业运行正常。但是，如果计划在几天后运行 cron 作业（即计算机至少已重新启动一次），则该 cron 作业将被错过。

此外，每次当我使用“crontab -e”在“nano”编辑器中编辑crontab文件时，顶行显示我正在编辑不同的文件，例如

File : /tmp/crontab.PLwi9Z/crontab
File : /tmp/crontab.degfpN/crontab
File : /tmp/crontab.odqbkT/crontab

我想知道这对于 crontab 来说是否正常，以及如何安排作业在几天后运行（即在几次重新启动后）。我使用的是 Ubuntu 12.04 amd64 系统。

感谢您的任何建议。

我有一个 AWS Lightsail 实例（1GB RAM 实例）运行一个相对较新的网站（即几乎没有流量）。它正在运行 nginx 和 PHP-FPM 7.3（也尝试过 7.2）和 MariaDB。所有这些都在 CentOS 7 下。

在 AWS 免费套餐下一切正常。我运行了一个 T2.micro EC2 实例和一个 T2.micro RDS 实例。Lightsail 有点……更敏感。为了使 Lightsail 正常工作，我将 PHP-FPM 切换为ondemand

ondemand - 启动时不创建子项。当新请求连接时，子节点将被分叉。

我必须这样做，否则 MariaDB 会随机崩溃。这似乎不会影响下面的问题。

Wordpress 管理面板停止正常工作，每个人都说要CONCATENATE_SCRIPTS关闭。这有效......主要是。帖子和模板的编辑器出现故障。没有人能够给我一个线索为什么。环顾四周，我自己发现了一些东西。

不工作的页面没有完全加载。随着CONCATENATE_SCRIPTS上，CSS文件被加载在一个巨大的页面。因为这无法完全渲染，所以浏览器会忽略 CSS 和 JS 文件。CONCATENATE_SCRIPTS通过简单地将它们拆分为更小且易于加载的组件文件来解决这个问题。但是编辑页面无法拆分，调试底层问题一直让人抓狂。我收到 200 响应和一些数据

但是页面绘制不完整。我想说也许 80-90% 的 HTML 都在那里，但被切断了。在从这里开始的部分（JS 块）

wp.apiFetch.use( wp.apiFetch.createPreloadingMiddleware( {"\/":{"body":{"name":"S

它只是突然结束，而且每次都在同一点。就好像 PHP-FPM 或 nginx 刚刚停止，但没有任何错误日志（关于这种类型的设置的大多数其他问题都是针对根本没有绘制的页面）。更奇怪的是，它不是在较小的页面上这样做，而是在非常长的页面上这样做。没有偷窃时间，top并且实例似乎没有承受任何严重的负载，所以我不确定它为什么会这样做。我重新加载了所有文件，甚至建立了一个单独的 WP 站点来测试这个，他们都这样做了。

根据评论，我打开了 nginx 调试日志记录并发现

2019/08/07 02:33:08 [crit] 1461#0: *47 open() "/var/lib/nginx/tmp/fastcgi/3/00/0000000003" failed …