☰

切换 DNS 会破坏 https 重定向

tag-icon • tag-icon apache-2.2 domain-name-system .htaccess nameserver godaddy
切换 DNS 会破坏 https 重定向

我们（我的公司）最近将名称服务器从 GoDaddy 切换到了 Amazon。我们的网站仍然托管在 GoDaddy 上。在切换名称服务器之前，一切都运行良好。

我们有一个网站，如果最初输入的是 ，https://example.com它将重定向到。我们还有第二个网站，位于，解析为。这与从请求重定向到 的第一个网站的工作方式相同。httpshttpexample.com/secondhttps://second.comhttpshttp

现在我们已经切换了名称服务器，https不再解析。如果我转到http://second.com/non-http-part不需要重定向的那个，它就可以正常工作。但是转到它重定向的索引，会导致页面根本无法加载。所有的都https://example.com不会加载。

我们联系了亚马逊，他们得出结论认为这是文件问题.htaccess。我觉得这很奇怪，因为这听起来更像是 DNS 问题，但这不是我的专业领域，所以我可能完全错了。

以下是我们的.htaccess文件。

rewriteengine on
rewritecond %{HTTPS} off
rewritecond %{HTTP_HOST} ^www.example.com$ [OR]
rewritecond %{HTTP_HOST} ^example.com$
rewriterule ^(.*)$ "https\:\/\/example\.com\/$1" [R=301,L]


#---[SITE PASSWORD PROECTION]
#AuthName "Restricted Area"
#AuthType Basic
#AuthUserFile /home/some_user/public_html/example/includes/security/.htpasswd
#AuthGroupFile /dev/null
#require valid-user
#---[CENTRALIZED REQUESTED]
<IfModule mod_rewrite.c>
RewriteBase /
</IfModule>
#---[OPTIONS AND ERROR DOCUMENT HANDLING]
Options -Indexes
IndexIgnore *
Options +FollowSymLinks
ErrorDocument 400 /index.php
ErrorDocument 401 /index.php
ErrorDocument 402 /index.php
ErrorDocument 403 /index.php
ErrorDocument 404 /index.php
#---[DENY ACCESS TO SPECIFIC FILES]
<FilesMatch "^(config\.php|\.htaccess|\.htpasswd|\.log|php\.ini|php5\.ini|readme\.html)">
Deny from all
Allow from 127.0.0.1
</FilesMatch>
rewritecond %{REQUEST_FILENAME} !-f
rewritecond %{REQUEST_FILENAME} !-d
rewriterule . /index.php [L]

答案1

根据我的经验，当我们迁移托管时，我们也需要迁移 SSL。只需获取 .pfx 密钥，然后在新托管提供商上进行设置即可。如果我们不在新服务器上配置 SSL，则 https 将无法工作。

答案2

尽管您的情况看起来很简单（毕竟这只是访问 HTTPS 网站时出现的问题），但事情还是有点复杂的。我将为您提供一些（希望是详细的）故障排除过程帮助。

让我们从这个开始：“...如果我去http://second.com/non-http-part不需要重定向，它可以工作......“

这表明“second.com”的 DNS 解析运行正常。无论如何，我会直接使用类似这样的实用程序进行检查主持人或者挖。这是为了保证您的系统不是依赖于一些可能指向 DNS 地址以外的地址的“hosts”文件。此外，它完全绕过了本地 DNS 缓存问题。

下面您可以看到一个例子：

verzulli@tablet-damiano:~$ host serverfault.com
serverfault.com has address 190.93.246.183
serverfault.com has address 190.93.247.183

verzulli@tablet-damiano:~$ dig serverfault.com
[...]
;; QUESTION SECTION:
;serverfault.com.               IN      A

;; ANSWER SECTION:
serverfault.com.        194     IN      A       190.93.247.183
serverfault.com.        194     IN      A       190.93.246.183

;; AUTHORITY SECTION:
serverfault.com.        90428   IN      NS      cf-dns02.serverfault.com.
serverfault.com.        90428   IN      NS      cf-dns01.serverfault.com.
[...]    
;; Query time: 63 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jun  6 09:15:13 2015
;; MSG SIZE  rcvd: 199

verzulli@tablet-damiano:~$

所以现在我们可以确定本地系统所依赖的 DNS 能够正确解析。

现在我要检查 HTTP 路径，确保本地系统和远程 Web 服务器之间没有任何东西破坏 HTTP 连接。这可能在透明代理上下文。请注意，我假设您的浏览器直接访问网络，没有配置任何显式代理。如果不是这种情况，请提供详细信息。

因此，我会检查系统的外部 IP 地址（您可以通过浏览器访问以下网站查看的 IP 地址）这) 与 (正常运行的) Apache 服务器的访问日志中报告的内容相同。就我而言，我得到：

  • 我的外部IP：aaa.bbb.ccc.ddd
  • 访问日志：aaa.bbb.ccc.ddd - - [06/Jun/2015:09:36:35 +0200] "GET / HTTP/1.1" 200 3650 "-" "[...]"

所以，现在我们知道，当访问 HTTP 站点时，我们会直接进入 Web 服务器（或者更好的是，中间不会出现容易被检测到的混乱）。

现在我们可以进行 HTTPS 测试。我不知道您是否可以交互式访问您的远程系统，所以我不确定您是否可以tcpdump在其上运行，所以让我们继续进行日志检查（因为我确定您可以访问您的日志文件）。我会：

  • 打开浏览器
  • 访问未运行的 HTTPS URL
  • 检查网络服务器 LOGS 是否报告正确的日志行

如果 LOGS 中没有出现任何内容，那么——假设您的 HTTPS 服务器记录正确——我们可以假设您的浏览器和服务器之间的 SSL 连接存在问题。

如果存在 LOG 行，那么我们可以说您的浏览器已经正确访问 HTTPS 服务器。

在这两种情况下，您都可以通过浏览器的“开发人员工具”获得更多帮助（Chrome/Chromium 和 Firefox 内置了该工具，可以使用 CTRL-SHIFT-I 启动）。开发人员工具可以跟踪浏览器注册的所有网络活动（参见“网络”选项卡），包括 HTTP/HTTPS 请求和相关响应。有了它，您还应该看到 HTTP 响应中的 REDIRECT，指向.htaccess规则中定义的 HTTPS URL。

最后注意：如果您的浏览器无法与 HTTPS 服务器建立 HTTPS 连接（因此，开发人员工具不会显示任何内容），您可以尝试使用openssl c_client实用程序，例如：

 openssl s_client -connect your.remote.https.site:443

上述命令将显示所有 SSL 握手，包括有关服务器证书的所有详细信息，并应引导您进入一个不可见的提示，等待您的常用 HTTP 方法（GET、POST 等，如“GET /”）。

遗憾的是，我无法向您提供更多详细信息。如果您仍有问题，请提供有关上述检查结果的信息。

相关内容