Files
cloud-chip.cn/.workbuddy/memory/2026-08-08.md
T
2026-08-08 23:40:18 +08:00

7.9 KiB
Raw Blame History

2026-08-08

调试:Gitea webhook "无响应"

  • 现象:Gitea 推送 webhook 测试无响应;手动部署(mes2 链路)正常。
  • 架构关键事实:push-to-deploy 的 webhook 接收器是独立服务,部署在子域 webhook.cloud-chip.cnIP 47.107.30.116),不属于本 Laravel 项目(cloud-chip.cn 主站);本工程的 deploy.sh 只是被叫醒后 git pull 的执行体。
  • 实测结论(2026-08-08):DNS/TLS/TCP443 全通,但 //hook 任意路径均 0 字节超时 → Nginx 活着、upstreamwebhook 应用)挂掉/卡死,导致"无响应"。根因在服务端应用层,与网络/证书/本工程无关。
  • 修复方向(未动手,用户选"只诊断"):在 47.107.30.116 上查 webhook 服务进程/Nginx error.log/上游端口,重启服务;接收器应改为后台执行 deploy.sh 并立即回 200,避免同步阻塞。
  • 安全提醒:Gitea webhook URL 里的 access_key 已暴露在聊天中,建议轮换。

修复:config/database.php 弃用告警(PHP 8.5

  • 现象:PHP 8.5 报 Deprecated: Constant PDO::MYSQL_ATTR_SSL_CA is deprecated, use Pdo\Mysql::ATTR_SSL_CA insteadconfig/database.php:36mysql 连接的 options)。
  • 修复:改为 (\class_exists(\Pdo\Mysql::class) ? \Pdo\Mysql::ATTR_SSL_CA : \PDO::MYSQL_ATTR_SSL_CA)。symfony/polyfill-php84 在 8.4 以下提供 Pdo\Mysql,故本地 8.3 与线上 8.5 均兼容。
  • 验证:php -l 通过;本地 8.3 class_exists 为 truePdo\Mysql::ATTR_SSL_CA = 1009(与旧常量同值)。app 代码中仅此一处使用 PDO::MYSQL_*
  • 部署提醒:上传后若 config 已缓存,需 php artisan config:clear(或重新 config:cache)方生效。

webhook 接收器架构(关键,已查清)

  • webhook.cloud-chip.cn 是宝塔站点,文档根 /www/wwwroot/webhook.cloud-chip.cn,启用「反向代理」。
  • 反代规则文件:/www/server/panel/vhost/nginx/proxy/webhook.cloud-chip.cn/2ff80e9159b517704ce43f0f74e6e247_webhook.cloud-chip.cn.conf,内容 proxy_pass https://47.107.30.116:8698;
  • 8698 = BT-Panel(宝塔面板主进程),不是 webhook 接收器 → 流量被送进面板,导致 Gitea 测试「无响应」。
  • 真正的接收器是宝塔 WebHook 插件URL 格式 access_key+param 可印证),默认端口 8443;当前未运行(ss 无 8443、无 hook 进程)。
  • 修复方向:安装/启动宝塔 WebHook 插件 → 反代目标改为 http://127.0.0.1:<插件端口> → nginx -s reload → 插件内自测 200 后再去 Gitea 测试。
  • 注意:真正的站点 vhost 在 /www/server/panel/vhost/nginx/(不是空的 /www/server/nginx/conf/vhost/)。

deploy.sh 增强 + 权限建议(cloud-chip.cn 生产)

  • deploy.sh 已加 php artisan config:clear + config:cachegit pull 之后),避免改 config/* 后 Laravel 仍读旧缓存。config:cache 失败仅告警不中断。已由用户手动推送。
  • 权限问题:生产服务器项目文件目前全归 root。要点:
    • 先确认 PHP-FPM 运行用户(宝塔默认 www):grep -r "^user" /www/server/php/*/etc/php-fpm.conf
    • 若 PHP-FPM 为 www:需 chown -R www:www /www/wwwroot/cloud-chip.cn,否则 storage/bootstrap/cache 写不进(日志/缓存/上传 Permission denied)。目录 755、文件 644,可写目录 775.env 限 640。
    • 若 PHP-FPM 以 root 跑:当前 root 归属"能用"但 Web 进程以 root 运行不安全,仍建议改 www 并改归属。
    • 与本次修复关系:弃用修复不依赖权限(config 文件 root 644 可被 Web 读取);关键是 deploy.sh 的 config:clear 让修复生效。权限是独立健壮性项,建议顺手做。
    • deploy.sh 中 config:cache 若以 root 运行会生成 root 所有的 config.php;因已先 config:clear 删除缓存,Laravel 直接读 config 文件,www 可读即可,无需纠结归属。

关键卡点:push-to-deploy 整条链断裂(2026-08-08 晚)

  • 用户删除了服务器 /www/wwwroot/cloud-chip.cn 内部内容(文件夹没了代码),但根因未变:本地 5 个提交从未推上 origin。
  • 实测(rev-parse + git cat-file):origin/main 仍停在 efc150c Initial commit,落后本地 5 个提交;config/database.php 在 origin 上缺失。即之前"手工推送"实际未成功。
  • 推送失败原因:git pushfatal: could not read Username for https://git.coolcoth.com: terminal prompts disabled —— 本机/本环境无 git.coolcoth.com 凭据,GCM 弹不出窗(注:git.coolcoth.com 是代码托管基础设施,地址正确;cloud-chip.cn 网站业务与 coolcoth.com 无关联,属不同主体)。
  • 恢复顺序(必须先做第1步):
    1. 把本地 5 个提交推上 origin(卡在凭据:需用户在能弹窗的终端 push,或提供 Gitea 写权限 PAT 让我用 URL 内联推送)。
    2. 服务器因文件夹已空,需重新 git clone(不能只 pull):cd /www/wwwroot && rm -rf cloud-chip.cn && git clone https://git.coolcoth.com/Lucanlee/cloud-chip.cn.git cloud-chip.cn
    3. 改归属 chown -R www:www + 目录755/文件644/可写775/.env 640。
    4. 必须去掉服务器端自动提交:宝塔 WebHook 接收器里有 git add -A && commit -m "实时更新" && push 逻辑(不在 deploy.sh,在 webhook 插件脚本里),会制造 origin 分歧导致后续 pull 冲突/拉不进新代码。删掉那段。
  • 提醒:webhook 接收器(宝塔 WebHook 插件,端口 8443)独立于本工程;用户删的是主站目录,不影响接收器,故 webhook 仍能触发,只是 deploy.sh 的 git pull 现在因目录空而失败。

安全/SEO/GEO 审计修复(2026-08-08 晚)

  • 来源:IMA 知识库「网站测试」→ SECURITY_SEO_AUDIT.md(扫描 2026-08-06,对象 cloud-chip.cn)。
  • 已落地(代码,提交 63431dd):
    • SEO-02Product::seoTitle() 去掉品牌后缀(app/Models/Product.php),视图统一 - $siteName,消除产品页标题品牌重复。
    • SEO-05/Geo-03:布局加 WebSite+SearchAction;产品页 Product+BreadcrumbList;文章页 Article+BreadcrumbList(含作者/发布日期)。用 JSON_HEX_TAG 防 XSS。
    • SEO-06:布局加 hreflang 自引用(zh-CN/x-default)。
    • SEC-02public/.well-known/security.txt。GEO-05public/llms.txt。
  • 已核验通过:SEC-04(本地 .env APP_DEBUG=false 等);SEO-01(全站区块已 h2,首页 h1 来自 Hero 富文本,属后台编辑规范)。
  • 未自动改(标记待办,详见 docs/SECURITY_SEO_REMEDIATION.md):SEC-01/REL-03CSP unsafe-inline,需 Tailwind 构建重构)、REL-02(公开页缓存,避免 CSRF 419 故全局 no-store)、REL-01/PHY-01~04CDN/WAF/多实例/备份,云端操作)、SEC-03composer 过旧无 audit 命令)、SEO-03/04(品牌名/title 堆砌,来自后台 site_name/seo_title_default 设置)、GEO-01/02/04/06 等(内容侧)。
  • 本地记录文档(供未来开发者):CHANGELOG.md + docs/SECURITY_SEO_REMEDIATION.md(逐项状态总表 + 改动位置 + 上线 curl 自检清单),已随 63431dd 提交。
  • 推送:凭据仍在本机环境拿不到,需用户从终端 git push origin main(用户此前选「我从本机终端推」)。

澄清(2026-08-08 23:29 记录,23:4x 修订)

  • 用户声明:cloud-chip.cn 网站/业务 与 coolcoth.com 网站/业务 没有任何关系(非同一主体/品牌)。
  • 但代码托管(Gitea)确实在 git.coolcoth.com,该地址正确、保持不动——coolcoth.com 在此仅作 Git 托管基础设施(类比用 GitHub 托管),不代表两网站有关联。
  • 因此此前「remote 误配、须改为 cloud-chip.cn 自有 Gitea」的判断已撤销git remote origin 维持 https://git.coolcoth.com/Lucanlee/cloud-chip.cn.git 不变。
  • 给未来开发者的提示:不要因为 git 主机在 coolcoth.com 就误判 cloud-chip.cn 归 coolcoth.com 所有;二者仅在「代码托管于该 Git 服务」这一点上有关,网站/品牌/业务彼此独立。