从“端口无法访问”到本地环境问题——朋友的博客踩坑记录

在决心踏入计算机的世界之后，我们总会勇敢踏步，朝着某个方向走去。也许那里是堵墙，也许墙上贴着前辈们的经验，只要有怀揣一颗热爱探索的心，总归能找到答案。

在发现属于自己的答案之前，没有一帆风顺的路。

问题与推论之间模糊的界限

「在吗」起手

M 给我发了一条微信，询问我「在吗」。

我在，我在暑期留校，我在食堂为数不多开放的档口等还算能吃的饭。

M 讲「公网 IP + 端口号无法访问」。

我的脑海中冒出许多种想法：「会不会是家庭宽带想要从公网访问」「会不会是服务器防火墙没有放行端口」「会不会是自己写的服务没有侦听所有网卡」「会不会是低位端口在路途中被拦截了」……

我问了一连串问题。「哪里来的公网 IP？」「什么类型的服务？」「SSH 能否连接？」

• 「哪里来的公网 IP」：判断是否真的拿到了公网 IP。
• 「什么类型的服务」：判断是成品引擎还算自己写的后端代码。
• 「SSH 能否连接」：判断IP上的其他端口能否连接。

弄清问题

起到关键作用的是后来 M 发来一张宝塔面板的截图。

谢天谢地，我终于弄明白他讲的问题是「服务器上通过宝塔面板搭建的网站无法访问」了。

我问「访问报什么错」。

他讲「直接无法访问」。天哪。

几句聊天之后，饭已经好了。先吃饭吧。

在饭送进嘴边之前，我认真思考了一下，和 M 约定下午亲自找他看看，不然可能说不清、可能修不好、可能造成一些破坏性的影响。

清理环境

中午睡醒已经是两点多了，下午解决完手里部分要紧的事情已经是三点半了。我给 M 发了消息，前往几十步路之远的他所在的实验室。

M 把他的工位让给我，我坚持让他搬一张椅子坐下，而不是站在旁边。

电脑开了很多窗口。浏览器里有很多标签页。

我用 Windows 的虚拟桌面功能，把问题相关的窗口和标签页放在新桌面里。

错误推论

我先照着 M 的思路，检查了公网 IP、服务商提供的防火墙、宝塔面板内的防火墙，最后才打开了那个「无法访问」的服务器上的公网 IP 的 80 端口。

访问网址，我的面色有些许变化。

「你看，你说的这个公网 IP + 端口真的无法访问吗？」我问。

「是啊，就这样打不开。」他答。

纯白色的画面映照着我的脸，屏幕上没有任何报错信息。

「端口是通的，这个网页已经加载好了，」我这样讲，「是你给 Nginx 提供的首页是空的，而不是无法访问。」

表面问题与实际意图的距离

问题环境

我快速扫视服务器。同时简单问了一些信息。

Ubuntu 系统。实例名叫 Windows Server。

没有配置 SSH。宝塔面板的终端功能不能使用。通过服务商提供的网页终端执行命令。

国内服务器，没有备案。有域名。

宝塔面板的 Nginx 提示未安装。怪事。

真正需求

他想搭博客。

搭博客起步阶段不用买服务器，使用静态托管服务即可。

博客不像是抖音爆款视频，缺乏服务器续费支持或长期内容输出，很难让自己或他人获益。

所以选择静态部署服务吧，既能防止续费困难而使得热爱更新的博客蒙尘，也能简化流程，让尝鲜选手快速吃上自建博客的体验。

本地开发环境有些许 messy

博客本体

这个博客文件夹没有初始化为 Git 仓库，使用 hexo-deployer-git 将生成的静态页面部署到 GitHub 仓库。博客主题文件夹使用 git clone 命令克隆，这样做有几个问题：

• 博客源文件未部署到 GitHub，容易丢失。
• 更改内容后不仅需要提交 git，还需要执行 hexo deploy 命令。
• 未使用 git submodule 管理主题文件夹，不好使用在线部署功能。

npm 环境

在使用 npm 管理包的过程中，我留意到更新项目依赖的过程中报 EPERM 错误，经检查是普通用户没有写入 npm 缓存文件夹的权限。这种情况一般是有软件安装到分区根目录，导致全盘读写权限被修改。不过他的情况并非如此，而是照着网上的教程，使用管理员权限的命令行配置了全局包、缓存路径，不配还好，这一配，就是环境问题。

「对，因为 C 盘空间有点小。」他讲。

修改了全局包和缓存文件夹的权限后，安装包不报错了。不过明明他配置过 npmmirror 镜像源，但是下载依赖的速度特别慢。查不出原因，索性重装 Node.js 环境吧。

winget remove nodejs

🥺又报错了。

这台电脑虽然是 Windows 11，但是已经很久没更新了，不支持软件包安装程序提供的 winget 命令。从系统设置卸载吧。

环境蓄力中

折腾一番，准备重装 Node.js，听闻 Node.js 是最近才安装的，想必安装包还在本地，兜兜转转找一圈没找到。

「安装包在迅雷里。」他讲。

安装之后，由于 ~/.npmrc 配置文件或是其他什么配置文件还在，下载慢的问题依旧，我也懒得换源了，直接用 pnpm 管理依赖吧。

npm install -g pnpm
pnpm setup
pnpm add -g pnpm
npm remove -g npm

可惜是用户文件夹名称是中文，pnpm 无法正常配置，路径变成了乱码。

从服务器修到电脑本体

中文用户文件夹名

「欸，这个刚装电脑不久就发现了，但是我一直不会改。」他继续讲。

「淘宝搜索“用户名中文改英文”，五到十块钱就能搞定。」我答，「既然遇到问题了，那就顺便改一下吧。」

当然，我也是当场上网查找的 修改教程。

得，又报错了，家庭版没有管理选项。为了减少对环境的影响，也为了避免扩大环境维护的范围，我并未将家庭版系统升级到专业版。

内置的 Administrator 不好启用，我索性断网（为了新建离线账户）新建了另一个管理员账户。

切换账户依然占用

切换账户后，我在注册表里找到并修改了原用户的用户文件夹路径配置，对应修改文件夹名的时候发现文件夹被占用，在任务管理器里关闭了几个可疑进程后问题依旧。

没事，还能救。

只要从 U 盘启动 PE 系统，就可以直接修改用户文件夹名了。

穿过几个走廊，我从自己工位取出了 U 盘。它安装了 Ventoy，带有 PE、Windows 和 Linux 的安装镜像。它又要出山了。

盘符图标上的小锁

在重启到 PE 之前，需要做好完全准备——比如，解决掉分区图标上代表 BitLocker 的小锁，起码确保知道恢复密钥。

说起这个锁，来头可就大了：不少用户在不知情的情况下变动分区，触发了 BitLocker 安全机制，开机显示「输入恢复密钥以进行恢复」的提示。有的按照提示找到了恢复密钥，进入了系统；有的微软账户里并未同步 BitLocker 密钥，便永远地失去了电脑内的所有数据。

我喊 M 在手机上先行登录微软账户网站，检查恢复密钥。

M 的账户里没有 BitLocker 密钥。

还好先行查看了，不然如果一会触发了 BitLocker 的话要出大问题。

在“设备加密”设置里关闭了开关，看着解密进度条一点一点推进，我心力交瘁地瘫在 M 的工位上。

PE 启动

「来杯奶茶吧，想喝什么？」M 问。

「豆乳玉麒麟不错，怎样？」M 继续问。

我又陷入久远的沉思了。之前喝过一杯豆乳玉麒麟，也是帮人解决电脑问题的酬劳。

等设备加密完全关闭以后，我重启进入 BIOS 关闭了安全启动，又进入 U 盘启动 PE 系统，改好了文件夹名。

分区「栓」

「我看不少软件被手动移到 D 盘了，所以顺便给 C 盘扩个容吧，把 D 盘空间分给 C 盘，有助于减少使用者的空间焦虑。」边操作着，我的动作停滞了。

C 盘和 D 盘之间横亘着一个 S: 分区、Ubuntu 的 ESP 分区、Ext4 格式的根目录分区、家目录分区。

我心里默算了一下，C 盘和这几个分区的大小加起来，刚好是 200 GB。

经过询问和检查，S 盘并没有什么重要内容，迁移一部分文件到 D 盘后，便把 S 盘的十几 G 空间归还给 C 盘了。

PATH 被分解

重启后，观感正常，删除之前临时新建的管理员账户。

根据教程，检查环境变量里残余的旧用户名。

再次发现情况：PATH 里原中文用户名的部分是乱码，并且出现了多个意外的分号将原先的单个路径断成多个路径。情况新到我没有见过，也在网上搜不到类似现象。

稍微收拾一下吧，npm 不知道什么问题下载慢，但 pnpm 应该算能用了。

为了丝滑部署博客也是煞费苦心

部署博客的核心要点

把奶盖和黄豆粉倒入奶茶，轻轻摇匀，小口啜饮。

可以开始优雅的博客部署环节了。

删除通过 git clone 克隆的原主题文件夹，使用 git submodule add 主题.git themes/主题名 添加主题。这样便可以之间在 Git Push 时云 build，而不用 hexo deploy。

同时，pnpm 下载包的体验十分顺畅，丝毫没有先前 npm 的凝滞感。

pnpm install -g hexo-cli
pnpm update --save
hexo cl; hexo s

本地运行博客的观感正常。

Git submodule 的轻松实践

命令比较强劲，审慎使用，确保做好备份。

git rm -f --cached themes/主题文件夹
git submodule add 主题git地址 themes/主题文件夹

可以推送了。

阻止推送

奶茶中的冰已经失去了硬朗的外形。终端里留着 Git 推送被阻止的信息。好一个丝滑未半而中道遇阻啊。

经检查，M 在 GitHub 设置中启用了阻止会暴露个人电子邮件地址的命令行推送。

我关掉这个选项，试图让博客部署重新顺畅起来。

选择静态部署服务

我又喝了一口豆乳玉麒麟，豆乳玉麒麟的口感很丝滑，不愧是热门产品。

「有身份证、学生证或者驾驶证吗？GitHub 有没有绑定 QQ 邮箱之外的邮箱？」我问。

得到否定的答案，严格注册风控 Netlify 便不可选了。

我带他注册了 Cloudflare 账号，验证了邮箱。在 Pages 服务页面绑定了 GitHub 仓库，填写好了部署命令和输出目录。绑定了域名。

天哪，又卡住了。主域名（@）使用 Cloudflare Pages 服务时，需要使用 Cloudflare 的 DNS 服务器。

迁移 DNS

奶茶喝得太快，胃里感到了些许凉意。

打开腾讯云。扫码登录。查看域名。修改域名的 DNS 服务器。再次扫码验明身份。

在 Cloudflare 设置好解析记录，差不多算是完成了。

小炒菜

进度比预想中的慢了不少，之前和另外几个朋友约好一起拼的小炒菜到了。暂时和 M 分别一会，他还想听一听博客后续如何推送更新。

托着盒饭就着菜，我吃完了米饭。提上豆乳玉麒麟继续找 M 了。

Git 三部曲

简短地，我告诉他：

• 写博客文章，保存
• 如果修改配置需要参阅主题文档，修改后执行 hexo cl 清除缓存
• 通过 hexo s 在本地预览
• 通过「Git 三部曲」提交到 GitHub，触发云端博客更新

  git add .
  git commit -m "提交信息"
  git push
  

我演示了一遍，M 自己也做了一遍。会了。

我把仅剩几块冰的奶茶留在了他的垃圾袋里。

窗外的鸟儿向朝天空飞去，教学楼实验室工位上的大学生敲着键盘，也在计算机领域里迈步前进。

写在题外

写这篇文章的动机

可能有人认为我写这篇文章有些过于苛责博客新手，但写此文是经过深刻考虑的。

M 在 2023 年 6 月用 GitHub Pages 搭建了博客，当时博客里只有一篇 Hello World 和一篇正文只有几个字母的文章。除了在同年 11 月提交了空文件并设置了域名之外，没有任何的内容更新。

而 2024 年 7 月我帮助 M 修复“新博客无法访问”至今，他的博客里也没有任何文章。

我不愿让自己付出的努力落空为一个没有内容的博客网站，于是就写了这篇文章，希望能把过程转化为可供参考的经验，帮助到真正愿意奉献到内容产出领域的人。

关于大学技术圈里刮起的博客之风

最近有不少同学先后搭建了属于自己的博客。搭建博客是好事，分享内容是乐事，长期维护是难事。

博客之魂在于内容。表面形式之亮丽固然悦目，但内容之实才得以赏心。

关于系统环境配置

「少即是多」，配置环境前一定要审慎权衡。切莫引入非必要的配置，让问题更加复杂甚至扑朔迷离。

「把所有软件装在 D 盘」「配置文件的超级堆砌」「永久关闭系统、软件更新」都是不建议的做法。电子设备服务于人类，而我们不应再为「伪教程」规训教化。

就像对于「怎么充手机不伤电池」「空调多少度最省电」这些问题的态度一样，人应当顺从本心，不要为「如何配置」而配置。

以上。