背景
最近在配置我的云服务器时,我遇到了一个有趣的网络问题。虽然能够通过 SSH 连接到服务器,也可以通过域名访问服务,但是在尝试通过 IP 地址和端口直接访问服务器上的服务时,却无法成功。一开始,我对这个问题感到困惑,但最终通过一系列的调试步骤找到了原因并解决了问题。
发现问题根源
问题根源的发现始于我使用外部服务检查服务器的公网 IP 地址。我注意到,虽然服务器有一个独立的公有 IP 地址,但通过外部服务显示的公网 IP 地址却属于 Cloudflare。
命令如下:
ubuntu@ip-172-31-8-225:~$ curl https://ipecho.net/plain
104.28.253.218
其中 104.28.253.218
属于cloudflare的cdn。
这启发我思考,这可能是由于服务器上的 Cloudflare WARP 设置所致。
Cloudflare WARP 的影响
Cloudflare WARP 是一种网络优化和安全服务,它可以改变服务器的公网 IP 地址,并通过 Cloudflare 的网络来路由流量。我意识到,WARP 可能在无意中拦截了对服务器的直接 HTTP 访问尝试。
解决步骤
-
停止 WARP 服务:
我首先在服务器上停止了 WARP 服务:sudo systemctl stop wg-quick@wgcf
这个命令停止了名为
wgcf
的 WireGuard 接口,这是 WARP 使用的技术。 -
测试访问:
停止 WARP 服务后,我再次尝试通过 IP 地址和端口访问服务器,这一次成功了。这证实了 WARP 是导致问题的根源。 -
确认问题解决:
为了确保问题彻底解决,我检查了服务器的网络配置,并确认没有其他潜在的问题影响网络访问。
学到的教训
- 理解工具的影响:虽然像 Cloudflare WARP 这样的工具可以提供网络优化和安全保障,但它们也可能对服务器的网络行为产生意想不到的影响。
- 调试技巧:在遇到复杂的网络问题时,检查各种角度和组件至关重要,包括但不限于服务配置、防火墙规则、DNS 设置和任何中间件。
- 外部服务的重要性:使用外部服务来查看服务器的公网 IP 地址是一个很有用的调试手段,尤其是在处理可能涉及第三方服务的情况时。
结论
这次经历不仅帮助我解决了一个具体的网络问题,也加深了我对云服务和网络配置方面的理解。它强调了在现代云计算环境中,了解和正确配置网络和相关服务的重要性。