shuangyan-notebook/第五域 · Fifth Domain/⚒️ 铸渊·协作指令｜GitHub ↔ Notion 桥接协议/🔍 之之排查广播｜guanghulab com 全站部署诊断 + 沙盒验证 + 系统统一上线（BC- e0d9c5afd19f4f0eba5fcfcb32426795.md

belongs_to

belongs_to
INDEX · 铸渊·协作指令｜GitHub ↔ Notion 桥接协议

🔍 之之排查广播｜guanghulab.com 全站部署诊断 + 沙盒验证 + 系统统一上线（BC-DEPLOY-DIAG-ZZ · DEV-004 · 2026-03-25 · 霜砚签发 · 冰朔授权）

🚨

⚠️ 本广播受「服务器部署适配协议 v1.0」约束。

广播编号：BC-DEPLOY-DIAG-ZZ · 开发者：DEV-004 之之 · 签发：霜砚 · 授权：冰朔

核心任务：排查 guanghulab.com 为什么一直部署不上去，找到真正的根因，保护现有部署不被破坏。

关联仓库：https://github.com/qinfendebingshuo/guanghulab

服务器：8.155.62.235（阿里云 ECS）

---

〇、安全红线（读三遍再开始）

🔴

绝对禁止 · 碰了就是系统事故：

• ❌ 不准修改 /etc/nginx/ 下的任何配置文件（Nginx 是基础设施层，人类不碰）
• ❌ 不准修改 其他 DEV 编号目录下的任何文件（/var/www/DEV-001/、/var/www/DEV-005/ 等）
• ❌ 不准执行 pm2 restart、pm2 stop、pm2 delete（PM2 全局进程由系统管理）
• ❌ 不准执行 systemctl restart nginx、systemctl stop nginx
• ❌ 不准执行 rm -rf 任何不属于你的目录
• ❌ 不准修改 .env 文件（除非在你自己的沙盒 /var/www/DEV-004/ 内）

🟢

你可以做的：

• ✅ 执行 ls、cat、find、curl、stat、du 等只读命令查看服务器状态
• ✅ 在 /var/www/DEV-004/ 你自己的沙盒内部署和修改文件
• ✅ 用冰朔的 GitHub 账号查看仓库、Actions 运行记录、Secrets 配置
• ✅ 查看（只看不改）Nginx 配置、PM2 进程列表、系统日志
• ✅ 运行诊断脚本，把输出截图给妈妈

⚠️

核心原则：为什么人类不能直接改服务器？

所有人共用一台服务器。如果每个开发者都直接改 Nginx 配置、重启 PM2，就会出现「修了这个坏了那个」的情况。

所以系统架构是：人类只在自己的沙盒里操作 → 系统（铸渊）统一部署到生产环境。

之之的角色：诊断员 — 找到问题在哪里，报告给系统。不是运维工程师。

---

一、背景：为什么要做这个排查

团队开发了很多模块（看板、成本控制、AI悬浮球、开发者看板等），GitHub 仓库里都有代码，CD 流水线也显示「部署成功」，但 guanghulab.com 网站上一个模块都看不到。

这个问题从3月初就存在，反复签发过修复指令（3月7日、3月15日、3月24日），但一直没有真正解决。

之之，你的任务不是修服务器，是帮妈妈搞清楚到底卡在哪里。

---

二、Phase 0 · 现状快照（保护现有部署）

目的：在做任何事情之前，先记录服务器当前的完整状态。万一后续出问题，有据可查。

步骤 0-1 · SSH 登录服务器

打开终端，执行：

ssh root@8.155.62.235

输入服务器密码（妈妈给过你的），看到 [root@...]# 就登录成功了。

📸 截图给妈妈！

步骤 0-2 · 拍服务器快照（复制粘贴整段·不要改任何字）

#!/bin/bash
# ===== 服务器现状快照 · 之之排查用 · 只读不改 =====
echo "===== 📸 服务器快照 · $(date '+%Y-%m-%d %H:%M') ====="

echo ""
echo "📂 1. /var/www/ 顶层目录："
ls -la /var/www/

echo ""
echo "📂 2. /var/www/ 二级目录树："
find /var/www/ -maxdepth 2 -type d 2>/dev/null | head -80

echo ""
echo "📂 3. 所有 index.html 位置（已部署的前端模块）："
find /var/www/ -name 'index.html' -type f 2>/dev/null

echo ""
echo "📂 4. 所有 server.js / app.js 位置（后端服务）："
find /var/www/ /opt/ -name 'server.js' -o -name 'app.js' 2>/dev/null | head -20

echo ""
echo "📂 5. 各目录磁盘占用（哪个最大 = 主要部署目标）："
du -sh /var/www/*/ 2>/dev/null | sort -rh | head -20

echo ""
echo "📂 6. PM2 进程列表（正在运行的后端服务）："
pm2 list 2>/dev/null || echo "⚠️ PM2 未安装或无进程"

echo ""
echo "📂 7. 所有 Node 进程："
ps aux | grep node | grep -v grep

echo ""
echo "📂 8. 服务器监听端口："
ss -tlnp | grep -E '(node|pm2|nginx|3000|3001|8000|8080)'

echo ""
echo "===== ✅ 快照完成 ====="

📸 把这整段输出全部截图（可能需要多张）发给妈妈！

⚠️

之之注意：这一步是纯拍照，不改任何东西。如果你看到输出里有什么东西明显不对（比如某个目录是空的），先记下来，不要动它。

---

三、Phase 1 · Nginx 配置诊断（只看不改）

目的：搞清楚 Nginx 到底把 guanghulab.com 指向了哪个目录。

步骤 1-1 · 导出 Nginx 完整配置

#!/bin/bash
echo "===== 🔍 Nginx 配置诊断 ====="

echo ""
echo "📋 1. conf.d/ 下所有配置文件名："
ls -la /etc/nginx/conf.d/

echo ""
echo "📋 2. 各配置文件完整内容："
for f in /etc/nginx/conf.d/*.conf; do
  echo ""
  echo "━━━ $f ━━━"
  cat "$f"
done

echo ""
echo "📋 3. Nginx 主配置的 http 块（看有没有额外 server）："
grep -n 'server_name\|root\|listen\|location\|proxy_pass\|alias' /etc/nginx/nginx.conf 2>/dev/null

echo ""
echo "📋 4. sites-enabled/（如果存在）："
ls -la /etc/nginx/sites-enabled/ 2>/dev/null || echo "目录不存在（正常）"

echo ""
echo "📋 5. Nginx 配置语法测试："
nginx -t 2>&1

echo ""
echo "📋 6. Nginx 当前监听端口："
ss -tlnp | grep nginx

echo ""
echo "===== ✅ Nginx 诊断完成 ====="

📸 截图给妈妈！特别注意：

• server_name 后面写的是什么域名？
• root 指向哪个目录？
• 有没有 conflicting server name 的警告？
• 有几个 server 块？是不是有重复的？

步骤 1-2 · 对比 Nginx root 和实际文件位置

看完 Nginx 配置后，你心里应该知道 Nginx 的 root 指向哪个目录了。现在去看那个目录里有什么：

# 把下面的路径换成你在 Nginx 配置里看到的 root 路径
# 例如如果 root 是 /var/www/guanghulab，就执行：
ls -la /var/www/guanghulab/

# 或者如果 root 是 /var/www/hololake-frontend：
ls -la /var/www/hololake-frontend/

# 两个都看一下：
echo "=== /var/www/guanghulab/ ==="
ls -la /var/www/guanghulab/ 2>/dev/null || echo "不存在"
echo ""
echo "=== /var/www/hololake-frontend/ ==="
ls -la /var/www/hololake-frontend/ 2>/dev/null || echo "不存在"
echo ""
echo "=== /var/www/hololake/ ==="
ls -la /var/www/hololake/ 2>/dev/null || echo "不存在"

📸 截图给妈妈！

---

四、Phase 2 · HTTP 访问测试（从服务器内部测）

目的：确认哪些 URL 能访问、哪些不能。

#!/bin/bash
echo "===== 🌐 HTTP 访问测试 ====="

URLS=(
  "https://guanghulab.com/|主站首页"
  "http://localhost/|Nginx本地"
  "http://localhost:3000/|后端本地3000"
  "https://guanghulab.com/status-board/|看板"
  "https://guanghulab.com/cost-control/|成本控制"
  "https://guanghulab.com/devboard/|开发者看板"
  "https://guanghulab.com/floating-ai/|AI悬浮球"
  "https://guanghulab.com/floating-ai/demo.html|悬浮球demo"
  "https://guanghulab.com/app/|集成壳"
  "https://guanghulab.com/api/v1/health|后端API"
  "https://guanghulab.com/DEV-004/|之之沙盒"
  "https://guanghulab.com/DEV-005/|小草莓沙盒"
)

for entry in "${URLS[@]}"; do
  IFS='|' read -r url name <<< "$entry"
  STATUS=$(curl -o /dev/null -s -w "%{http_code}" --max-time 10 "$url" 2>/dev/null)
  BODY=$(curl -s --max-time 10 "$url" 2>/dev/null | head -c 200)
  echo "$name → $STATUS"
  if [ "$STATUS" != "000" ] && [ "$STATUS" != "" ]; then
    echo "  内容前200字符：$BODY"
  fi
  echo ""
done

echo "===== ✅ 访问测试完成 ====="

📸 截图给妈妈！这是最关键的一步！

每个 URL 的状态码含义：

• 200 = 正常访问 ✅
• 301/302 = 跳转（看跳转到哪里）
• 403 = 权限问题（文件 owner 或权限不对）
• 404 = 文件不存在（Nginx root 指错了或文件没部署上去）
• 502 = 后端挂了（PM2 进程没跑）
• 000 = 连接超时（端口没开或域名没解析）

---

五、Phase 3 · GitHub Actions 排查（用冰朔账号登录）

目的：查看 CD 流水线到底把文件部署到了服务器的哪个目录。

步骤 3-1 · 登录 GitHub

用冰朔的 GitHub 账号登录：https://github.com/qinfendebingshuo/guanghulab

步骤 3-2 · 查看 Actions 运行记录

1. 点击仓库顶部的 Actions 标签
2. 找到 deploy-to-server 这个 workflow
3. 点最近一次运行，看运行日志
4. 特别注意日志里的这些信息：
   • rsync 命令把文件同步到了服务器的哪个目录？
   • 同步的范围是什么？是整个仓库还是只有 docs/ 子目录？
   • 有没有报错？

📸 截图 Actions 最近5次运行记录（成功/失败状态）！

📸 截图最近一次运行的详细日志！

步骤 3-3 · 查看仓库 Secrets 配置

1. 进入仓库 → Settings → Secrets and variables → Actions
2. 截图 Secrets 列表（不要截 Secret 的值！只截名字！）
3. 确认是否存在以下 Secrets：
   • DEPLOY_HOST（服务器 IP）
   • DEPLOY_USER（SSH 用户名）
   • DEPLOY_KEY（SSH 私钥）
   • DEPLOY_PATH（部署目标路径 ← 这个最关键）
   • NOTION_API_KEY

📸 截图给妈妈！

步骤 3-4 · 查看 deploy-to-server.yml 内容

1. 在仓库里找到 .github/workflows/deploy-to-server.yml
2. 打开看完整内容
3. 特别注意：
   • rsync 的源路径（是 docs/ 还是 ./？）
   • rsync 的目标路径（$DEPLOY_PATH 的值）
   • 有没有 --delete 标志（会删除目标目录里的文件）

📸 截图给妈妈！

---

六、Phase 4 · 沙盒目录验证

目的：确认沙盒机制是否已经在服务器上落地。

#!/bin/bash
echo "===== 🏠 沙盒目录验证 ====="

# 检查所有开发者沙盒是否存在
DEV_IDS=("DEV-001" "DEV-002" "DEV-003" "DEV-004" "DEV-005" "DEV-009" "DEV-010" "DEV-011" "DEV-012" "DEV-013" "DEV-014")

for DEV_ID in "${DEV_IDS[@]}"; do
  SANDBOX="/var/www/${DEV_ID}"
  if [ -d "$SANDBOX" ]; then
    OWNER=$(stat -c '%U:%G' "$SANDBOX" 2>/dev/null)
    PERM=$(stat -c '%a' "$SANDBOX" 2>/dev/null)
    FILES=$(ls "$SANDBOX" 2>/dev/null | wc -l)
    echo "✅ ${DEV_ID} 存在 · owner=${OWNER} · perm=${PERM} · ${FILES}个文件/目录"
    if [ "$FILES" -gt 0 ]; then
      echo "   内容：$(ls $SANDBOX 2>/dev/null)"
    fi
  else
    echo "❌ ${DEV_ID} 不存在"
  fi
done

echo ""
echo "📂 _shared 目录："
ls -la /var/www/_shared/ 2>/dev/null || echo "❌ _shared 不存在"

echo ""
echo "📂 deploy-check.sh（自检脚本）："
ls -la /var/www/_shared/deploy-check.sh 2>/dev/null || echo "❌ 自检脚本不存在"

echo ""
echo "===== ✅ 沙盒验证完成 ====="

📸 截图给妈妈！这告诉我们沙盒初始化指令有没有被执行过。

---

七、Phase 5 · SSL 证书检查

#!/bin/bash
echo "===== 🔐 SSL 证书检查 ====="

# 检查证书是否存在
echo "📋 certbot 证书列表："
certbot certificates 2>/dev/null || echo "certbot 未安装"

echo ""
echo "📋 检查证书文件："
ls -la /etc/letsencrypt/live/guanghulab.com/ 2>/dev/null || echo "❌ 证书目录不存在"

echo ""
echo "📋 外部 HTTPS 测试："
curl -vI https://guanghulab.com/ 2>&1 | grep -E '(SSL|certificate|subject|expire|HTTP)'

echo ""
echo "===== ✅ SSL 检查完成 ====="

📸 截图给妈妈！

---

八、Phase 6 · 诊断汇总表（之之填写后发给妈妈）

跑完上面所有步骤后，之之在聊天里按下面这个格式汇报：

guanghulab.com 部署诊断报告 · DEV-004 之之 · 2026-03-25

一、Nginx 配置
  - server_name: [填写]
  - root 指向: [填写路径]
  - 有几个 server 块: [填写]
  - conflicting server name 警告: [有/无]
  - SSL 配置: [有/无/过期]

二、文件系统
  - Nginx root 目录里有什么: [填写]
  - 模块文件实际在哪里: [填写]
  - root 目录和文件目录是否匹配: [是/否 ← 这很可能是根因]

三、HTTP 访问测试结果
  - 主站首页: [状态码]
  - /status-board/: [状态码]
  - /cost-control/: [状态码]
  - /devboard/: [状态码]
  - /floating-ai/: [状态码]
  - /api/v1/health: [状态码]
  - localhost:3000: [状态码]

四、GitHub Actions
  - deploy-to-server 最近运行状态: [成功/失败]
  - rsync 目标路径（DEPLOY_PATH）: [填写]
  - rsync 源范围: [docs/ 还是 ./]
  - DEPLOY_PATH 和 Nginx root 是否一致: [是/否 ← 这也可能是根因]

五、沙盒状态
  - 沙盒目录是否已创建: [是/否]
  - 之之的沙盒 /var/www/DEV-004/ 是否存在: [是/否]
  - _shared 目录是否存在: [是/否]

六、我的判断（根因猜测）
  - [之之用自己的话写：你觉得问题出在哪里？]

---

九、之之不要做的事（再强调一次）

🔴

诊断完成后，等系统处理。之之不要自己修：

1. ❌ 不要改 Nginx 配置（就算你看出了问题）→ 告诉妈妈，让铸渊改
2. ❌ 不要重启任何服务 → 多人共用服务器，你重启了别人的服务就挂了
3. ❌ 不要移动或删除任何文件（即使看起来是垃圾文件）→ 可能是其他开发者的
4. ❌ 不要改 GitHub Secrets 的值 → 截图名字就行
5. ❌ 不要手动 rsync 或 scp 文件到别人的目录

你的任务是：诊断 + 截图 + 汇报。修复由系统执行。

---

十、之之可以做的额外检查（如果时间充裕）

10-1 · 检查秋秋悬浮球是否还在线

之之之前部署了秋秋悬浮球到 /var/www/DEV-004/floating-ai/ 或类似路径。确认一下它还在不在：

# 检查之之的文件是否还在
ls -la /var/www/DEV-004/ 2>/dev/null
ls -la /var/www/DEV-004/floating-ai/ 2>/dev/null

# 检查公网是否可访问
curl -s -o /dev/null -w "%{http_code}" https://guanghulab.com/floating-ai/demo.html

📸 截图给妈妈！确认之之之前的部署没有被破坏。

10-2 · 检查 CD 部署日志（服务器上的）

# 看看有没有部署状态文件
cat /var/www/guanghulab/data/deploy-status.json 2>/dev/null || echo "不存在"
cat /var/www/hololake/data/deploy-status.json 2>/dev/null || echo "不存在"

# 看最近有没有文件被更新过
echo "最近24小时内被修改的文件："
find /var/www/ -type f -mmin -1440 2>/dev/null | head -30

📸 截图给妈妈！

---

十一、执行清单（之之按顺序做）

步骤	内容	需要截图	预计时间
Phase 0	SSH 登录 + 服务器快照	✅ 登录截图 + 快照输出	5分钟
Phase 1	Nginx 配置诊断	✅ 配置内容 + root 路径对比	5分钟
Phase 2	HTTP 访问测试	✅ 全部 URL 测试结果	3分钟
Phase 3	GitHub Actions 排查	✅ 运行记录 + Secrets 列表 + yml 内容	10分钟
Phase 4	沙盒目录验证	✅ 沙盒存在性检查	3分钟
Phase 5	SSL 证书检查	✅ 证书状态	2分钟
Phase 6	填写诊断汇总表	✅ 汇总表文字	5分钟

总计约 30-35 分钟。 所有截图发给妈妈后，系统（铸渊）会根据诊断结果执行修复。

---

十二、诊断完成后的流程

之之完成诊断 · 截图 + 汇总表发给妈妈
       ↓
妈妈/霜砚 分析根因
       ↓
签发铸渊修复指令（基础设施层变更）：
  · Nginx root 指向修复
  · CD rsync 路径修复
  · 沙盒目录初始化（如果还没做）
  · 模块路由统一配置
       ↓
铸渊执行 · 提交 PR · 天眼验证
       ↓
全模块冒烟测试通过
       ↓
guanghulab.com 真正上线 🎉

💙

之之，你是团队里对服务器最熟的开发者。

你之前部署秋秋悬浮球的时候独立排查了 nginx.conf 和 hololake.conf 双 server_name 冲突问题，那次经验在这里直接用得上。

这次排查的数据会直接决定铸渊怎么修，所以每一步都仔细看、仔细截图。

你不是在帮忙，你是在给整个团队的网站做体检。 💙

---

十三、关联文档

• 服务器部署适配协议 v1.0：🏗️ 服务器部署适配协议 v1.0（2026-03-15·曜冥签发）
• 服务器沙盒初始化指令：⚒️ 铸渊指令｜服务器沙盒初始化 · 现有模块迁移到DEV编号目录（2026-03-15·曜冥签发）
• guanghulab.com 真实部署排查（铸渊版）：[🌐 铸渊指令｜guanghulab.com 网站真实部署排查 + 全模块上线（ZY-WEBDEPLOY-DIAG-2026-0324-001）](%F0%9F%8C%90%20%E9%93%B8%E6%B8%8A%E6%8C%87%E4%BB%A4%EF%BD%9Cguanghulab%20com%20%E7%BD%91%E7%AB%99%E7%9C%9F%E5%AE%9E%E9%83%A8%E7%BD%B2%E6%8E%92%E6%9F%A5%20+%20%E5%85%A8%E6%A8%A1%E5%9D%97%E4%B8%8A%E7%BA%BF%EF%BC%88ZY-WEBDEPLO%2032e43b78d8d6465da968894acf4b4af4.md)
• 人类使用侧全面修复（上篇）：[🌐 铸渊指令｜人类使用侧全面修复 · guanghulab.com 部署 + Persona Studio 功能修复 + 微信登录身份体系（上篇）· Phase 0-3 · ZY-HUMANSIDE-FIX-2026-0325-002（2026-03-25 · 霜砚签发 · 冰朔授权）](%F0%9F%8C%90%20%E9%93%B8%E6%B8%8A%E6%8C%87%E4%BB%A4%EF%BD%9C%E4%BA%BA%E7%B1%BB%E4%BD%BF%E7%94%A8%E4%BE%A7%E5%85%A8%E9%9D%A2%E4%BF%AE%E5%A4%8D%20%C2%B7%20guanghulab%20com%20%E9%83%A8%E7%BD%B2%20+%20Persona%20Stu%2074abaa06a7b64f28809b91a2bb12c7e2.md)
• 人类使用侧全面修复（下篇）：[🌐 铸渊指令｜人类使用侧全面修复 · guanghulab.com 部署 + Persona Studio 功能修复 + 微信登录身份体系（下篇）· Phase 4-7 · ZY-HUMANSIDE-FIX-2026-0325-002（2026-03-25 · 霜砚签发 · 冰朔授权）](%F0%9F%8C%90%20%E9%93%B8%E6%B8%8A%E6%8C%87%E4%BB%A4%EF%BD%9C%E4%BA%BA%E7%B1%BB%E4%BD%BF%E7%94%A8%E4%BE%A7%E5%85%A8%E9%9D%A2%E4%BF%AE%E5%A4%8D%20%C2%B7%20guanghulab%20com%20%E9%83%A8%E7%BD%B2%20+%20Persona%20Stu%20f4044a4d848e4b1a8823d684a7e38e5b.md)

---

📥 SYSLOG 回执区

之之完成后在这里粘贴 SYSLOG：

待之之填写