📋 Typecho API信息

1. Typecho Agent API
   特点: 专为LLM Agent设计的博客控制服务
   功能: 支持14个HTTP工具，包括文章管理、分类标签、图片上传等
   文档: https://xaomao.cc/index.php/archives/232/
   GitHub: https://github.com/chapaofan/typecho-server-and-skill
2. smcloudcat/typechoapi
   特点: 简单易用的Typecho API
   功能: 支持发布文章、搜索文章、获取文章、备份数据等
   GitHub: https://github.com/smcloudcat/typechoapi
   🚀 我已经为您创建了发布脚本
   脚本文件位置
   发布脚本: /home/qianlong/.openclaw/workspace/publish-to-typecho.sh
   配置文件: /home/qianlong/.openclaw/typecho-config.json
   使用指南: /home/qianlong/.openclaw/workspace/Typecho发布指南.md
   支持的功能
   ✅ 发布Markdown文档到Typecho
   ✅ 支持两种API类型（Agent API和simple API）
   ✅ 自动转换Markdown为HTML
   ✅ 标签和slug自定义
   ✅ 详细的日志记录
   ✅ 错误处理和故障排除
   配置示例
   Typecho Agent API配置：
   {
   "TYPECHO_API_TYPE": "agent",
   "TYPECHO_API_URL": "https://your-typecho-site.com/api",
   "TYPECHO_API_KEY": "your_api_key"
   }

smcloudcat/typechoapi配置：
{
"TYPECHO_API_TYPE": "simple",
"TYPECHO_API_URL": "https://your-typecho-site.com",
"TYPECHO_API_KEY": "your_token"
}
使用方法

发布文档到Typecho

./publish-to-typecho.sh /path/to/your/document.md "文章标题"

指定标签和slug

./publish-to-typecho.sh /path/to/your/document.md "文章标题" "[\"tag1\",\"tag2\"]" "article-slug"

我已经为您优化了proxy-check.sh脚本，添加了以下高级功能：

新增功能

状态持久化 - 使用状态文件记录代理状态
状态变化检测 - 检测状态变化并记录日志
详细日志记录 - 自动记录到日志文件
自动重试机制 - 失败时自动重试
守护模式 - 可作为服务持续运行
配置文件 - 支持外部配置文件

配置文件位置

/home/qianlong/.proxy-check/config.conf - 主配置文件
/home/qianlong/.proxy-check/status.log - 状态记录
/home/qianlong/.proxy-check/logs/ - 日志目录

使用方法

手动运行检查

/home/qianlong/.proxy-check.sh

守护模式运行（后台持续检查）

/home/qianlong/.proxy-check.sh daemon

查看日志

tail -f /home/qianlong/.proxy-check/logs/proxy-check-$(date +%Y%m%d).log

手动安装服务

1. 设置权限

chmod +x /home/qianlong/.proxy-check.sh

2. 复制服务文件

sudo cp /home/qianlong/.proxy-check/proxy-check.service /etc/systemd/system/

3. 重新加载systemd

sudo systemctl daemon-reload

4. 启用开机自启

sudo systemctl enable proxy-check.service

5. 启动服务

sudo systemctl start proxy-check.service

6. 检查状态

sudo systemctl status proxy-check.service

脚本现在具备企业级稳定性，会自动检测代理状态变化，记录详细日志，并在代理不可用时自动回退到国内访问。您可以通过日志文件监控代理状态变化。

Nginx 提示 403 Forbidden 错误，核心本质只有一句话：Nginx 找到了你请求的路径，但是它被某种规则或权限死死挡在门外，没有权力读取它。

这是 Web 开发中最容易遇到的“拦路虎”之一。请对照以下四大最常见的排查方向，像剥洋葱一样逐层解决：

🔑 原因一：文件或目录的系统权限不足（最常见）
Nginx 的工作进程（Worker Process）通常是以 nginx 或 www-data 用户身份运行的。如果你的网站目录属于 root 用户，且没有给其他用户读写权限，Nginx 就会直接甩你一个 403。

🛠️ 修复方法：
检查网站根目录的所有者：

Bash

假设你的网站根目录是 /usr/share/nginx/html

ls -ld /usr/share/nginx/html
将目录所有权移交给 Nginx 用户：

Bash

CentOS / RHEL 系统：

chown -R nginx:nginx /usr/share/nginx/html

Ubuntu / Debian 系统：

chown -R www-data:www-data /var/www/html
规范权限颗粒度（层级目录权限）：
Nginx 不仅需要目标文件的可读权限（r），还需要其所有上级目录的可执行权限（x）（否则无法进入目录）。

Bash

赋予目录 755 权限，赋予文件 644 权限

find /usr/share/nginx/html -type d -exec chmod 755 {} \;
find /usr/share/nginx/html -type f -exec chmod 644 {} \;
📄 原因二：缺少默认首页文件（如 index.html / index.php）
当你访问一个域名或 IP（例如 http://localhost/）而不指定具体文件名时，Nginx 会去对应的目录下寻找 index 指令指定的文件。如果找不到，且 Nginx 默认关闭了“列出目录”功能，就会报 403。

🛠️ 修复方法：
检查你的网站根目录下，是否真的躺着 index.html 或 index.php。

打开对应的 Nginx 配置文件（如 default.conf），检查 location / 块中是否正确配置了首页索引：

Nginx
location / {

root   /usr/share/nginx/html;
index  index.php index.html index.htm; # 👈 确保这里包含了你的首页文件名

}
如果你就是想让它像 FTP 一样列出整个目录的文件列表，可以在 location 块中强行开启自动索引（不推荐在生产环境开启）：

Nginx
autoindex on; # 默认是 off，改为 on 后不会再报 404/403，而是列出文件列表
🛡️ 原因三：SELinux 阻拦（CentOS / RHEL 系统的硬伤）
如果你是在 CentOS 或 RHEL 系统上刚迁移了网站目录（比如把数据从 /usr/share/nginx/html 挪到了 /data/www），SELinux 的安全上下文标签没有同步更新，它会直接熔断 Nginx 的跨目录读取行为。

🛠️ 修复方法：
快速诊断法： 临时将 SELinux 设为宽容模式，刷新网页：

Bash
setenforce 0
如果网页瞬间能打开了，100% 是 SELinux 的锅。

完美修复法（不关闭安全机制）： 给新目录打上 Nginx 专属的安全标签：

Bash
semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?"
restorecon -R -v /data/www
🚫 原因四：Nginx 配置文件中设置了访问控制（ACL）
检查你的配置文件里是不是不小心写了 deny 规则，把自己的 IP 或所有流量给误杀了。

🛠️ 修复方法：
检查 nginx.conf 或站点配置，看看有没有类似下面的绝杀字眼：

Nginx
location / {

deny 192.168.1.1; # 封禁了某个 IP
deny all;         # 🚨 这行会拒绝所有人访问！

}
如果有，将其注释掉或修改为 allow all;，然后重启 Nginx：systemctl restart nginx。

🔍 终极定位
如果上面的方法都试过了还是 403，直接去抓它的现行错误日志，日志里会明确写出是因为 Permission Denied 还是因为找不到 Index 文件：

Bash
tail -n 20 /var/log/nginx/error.log

将 Typecho 网站与局域网内的独立 MariaDB 服务器连接，是一种非常标准的动静分离/前后端分离架构。这能有效减轻 Web 服务器的压力，提升博客的并发性能。

既然你刚才已经打通了 MariaDB 的局域网 IP 访问，现在要把这两台服务器（A 机器：Typecho 网页服务器，B 机器：MariaDB 数据库服务器）彻底揉合在一起，请按照以下两端的标准步骤进行配置：

一、 数据库服务器端配置（MariaDB 所在的 B 机器）
必须确保数据库愿意接收来自 Typecho 服务器的连接，并且没有被防火墙挡住。

1. 检查网卡绑定（上一步已完成可跳过）
   确保 /etc/my.cnf 或 /etc/my.cnf.d/server.cnf 中的 [mysqld] 块下写的是：

Ini, TOML
bind-address = 0.0.0.0
修改后记得 systemctl restart mariadb。

2. 精准精准授权（安全规范）
   登录 B 机器的 MariaDB，为 Typecho 创建专属的数据库用户，并限制该用户只能由 A 机器（Typecho 服务器）的局域网 IP 登录：

SQL
-- 1. 登录数据库
mariadb -u root -p

-- 2. 给 Typecho 分配权限（请用实际的“Typecho服务器的局域网IP”替换下面的 192.168.1.50）
GRANT ALL PRIVILEGES ON 你的Typecho数据库名.* TO 'typecho_user'@'192.168.1.50' IDENTIFIED BY '你的强密码';

-- 3. 刷新权限
FLUSH PRIVILEGES;
EXIT;

3. 防火墙放行
   确保 B 机器放行了 3306 端口：

Bash
firewall-cmd --zone=public --add-port=3306/tcp --permanent
firewall-cmd --reload
二、 Typecho 服务器端配置（网页所在的 A 机器）
现在，我们需要让 Typecho 顺着局域网网线找到 B 机器。

1. 连通性肉搏测试（避坑神技）
   在 A 机器（Typecho 服务器）的终端里，先不要急着改代码，运行以下命令测试能否隔空摸到 B 机器的数据库端口：

Bash
curl -v telnet://192.168.1.100:3306 # 请将 192.168.1.100 换成 MariaDB 服务器的局域网 IP
如果屏幕提示 Connected to ...，说明局域网通路100% 完美连通。

如果提示 Connection timed out 或 Refused，说明 B 机器的防火墙没开，或者 bind-address 没改对。

2. 修改 Typecho 配置文件
   登录 A 机器，打开 Typecho 根目录下的 config.inc.php，找到 $db->addConfig 所在的代码块，将其修改为局域网内的连接参数：

PHP
$db = new Typecho_Db('Mysql', 'typecho_');
$db->addConfig(array (
'host' => '192.168.1.100', // 🚨 极其重要：填入 MariaDB 服务器的局域网固定 IP（不能写 localhost！）
'port' => '3306', // MariaDB 局域网网络端口
'user' => 'typecho_user', // 你在第一步中为 Typecho 创建的数据库用户名
'password' => '你的强密码', // 该用户的密码
'charset' => 'utf8mb4',
'database' => '你的Typecho数据库名', // 远程服务器上的数据库名称
'engine' => 'InnoDB',
), Typecho_Db::READ | Typecho_Db::WRITE);
Typecho_Db::set($db);
保存并退出。此时，刷新你的 Typecho 博客主页，所有的文章和数据就会开始通过局域网内网飞速向 MariaDB 服务器进行读写交互了！

改变 MariaDB 数据库的默认存放位置（通常是从 /var/lib/mysql 迁移到空间更大的目录，如 /data/mysql）是一个经典的系统运维操作。

为了确保数据绝对安全且迁移后服务能正常启动，请严格按照以下五个步骤进行操作：

1. 停止 MariaDB 服务
   在进行任何数据复制之前，必须先停止数据库服务。如果在服务运行时复制文件，会导致数据库文件损坏或数据不一致。

Bash
sudo systemctl stop mariadb

2. 复制数据并保留权限
   假设你要将数据迁移到 /data/mysql 目录下。使用 cp -a 或 rsync 极其关键，因为它们能完美保留原文件的所有者、所属组 (mysql:mysql) 以及安全权限。

Bash

创建新目录的基础路径

sudo mkdir -p /data

完整复制原数据并保留所有权限属性

sudo cp -a /var/lib/mysql /data/
复制完成后，确认一下新目录的权限是否正确：

Bash
ls -ld /data/mysql

正常情况应该看到所有者和组都是 mysql

3. 修改 MariaDB 配置文件
   打开 MariaDB 的配置文件。在 CentOS/RHEL 下通常是 /etc/my.cnf 或 /etc/my.cnf.d/server.cnf；在 Ubuntu/Debian 下通常是 /etc/mysql/mariadb.conf.d/50-server.cnf。

Bash
sudo vi /etc/my.cnf
找到 [mysqld] 标签，修改（或新增）datadir 和 socket 的路径配置：

Ini, TOML
[mysqld]
datadir=/data/mysql
socket=/data/mysql/mysql.sock
(重要提示)：为了让本地终端的 mysql 命令在不加参数时依然能直接连上数据库，建议在文件底部加上客户端的 socket 指向：

Ini, TOML
[client]
socket=/data/mysql/mysql.sock

4. 解决系统安全拦截 (SELinux / AppArmor)
   这是更改路径后最容易导致启动失败（Permission denied）的环节。Linux 的底层安全机制默认只允许数据库读取 /var/lib/mysql。

如果你使用的是 CentOS / RHEL (SELinux):
将原目录的安全上下文直接“克隆”给新目录，并刷新生效：

Bash
sudo semanage fcontext -a -e /var/lib/mysql /data/mysql
sudo restorecon -R -v /data/mysql
(注：如果你的系统没有 semanage 命令，可以通过 setenforce 0 临时关闭 SELinux 来让数据库先跑起来)。

如果你使用的是 Ubuntu / Debian (AppArmor):
修改 AppArmor 的路径别名配置：

Bash
sudo vi /etc/apparmor.d/tunables/alias
在文件末尾新增一行，建立路径映射：

Plaintext
alias /var/lib/mysql/ -> /data/mysql/,
保存后重启 AppArmor 服务：

Bash
sudo systemctl restart apparmor

5. 重启服务并验证结果
   环境全部调校完毕，重新拉起 MariaDB 服务：

Bash
sudo systemctl start mariadb
sudo systemctl status mariadb
如果服务显示绿色的 active (running)，登录进数据库终端进行最后验证：

Bash
mysql -u root -p
执行以下 SQL 语句：

SQL
SHOW VARIABLES LIKE 'datadir';
只要表格中返回的值是你的新路径（/data/mysql/），即代表迁移彻底成功！在系统稳定运行几天确认无误后，你可以放心地使用 rm -rf /var/lib/mysql 清理掉旧文件以释放旧盘空间。