news 2026/9/24 23:35:35

Typecho内网穿透实战：从本地博客到公网访问全链路解析

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
Typecho内网穿透实战：从本地博客到公网访问全链路解析

1. 这不是“搭个博客”那么简单：Typecho + 内网穿透的真实价值与典型误区

你搜“Typecho 搭建博客”，十篇教程里八篇开头就是“下载安装包、解压、配置数据库、访问安装向导”——看起来三分钟搞定。但真正用过的人知道，这仅仅是万里长征第一步。我从2015年第一次在阿里云ECS上跑Typecho，到后来在树莓派、NAS、甚至旧笔记本上反复折腾，踩过的坑比写过的文章还多。Typecho本身轻量、快、干净，但它天生是个“局域网居民”；而内网穿透不是魔法开关，它是把一根细线穿过一堵厚墙，既要穿得过去，还得让数据不丢、不卡、不被截断。今天说的“使用Typecho搭建个人博客网站，并内网穿透实现公网访问”，核心从来不是“怎么装Typecho”，而是“如何让一台物理上锁在你家路由器后面的设备，被全世界的浏览器准确、稳定、安全地找到并加载出你的文章”。关键词里的“内网穿透”四个字，才是真正的分水岭：它决定了你的博客是只能自己欣赏的草稿箱，还是能被搜索引擎收录、被朋友一键收藏的数字门牌。很多人卡在最后一步——明明本地能打开，手机连着4G却打不开，或者打开后图片全裂、评论发不出、后台登录跳转错误。这不是Typecho的问题，也不是你网络差，而是穿透链路中某个环节的协议没对齐、端口没映射对、HTTPS没兜住。下面我会像带徒弟一样，把从选型、部署、调试到长期维护的每一步掰开揉碎，不讲虚的，只说你打开终端、敲下命令、刷新页面时真正需要知道的东西。

2. 整体架构设计与方案选型：为什么选Typecho？为什么穿透不用frp或ngrok？

2.1 Typecho的不可替代性：轻量不是妥协，是精准克制

很多人问：“WordPress功能多，插件丰富，为啥不用？”——这话没错，但错在混淆了“功能多”和“你需要的功能”。我统计过自己三年来的博客操作：92%是写文章、改分类、换主题配色；3%是处理评论垃圾；剩下5%是偶尔调下SEO标题。WordPress为那5%的“可能用到”功能，常年挂着20多个PHP进程、MySQL里存着几百张表、每次升级都要备份整个wp-content目录。而Typecho呢？一个index.php入口文件，一套精简的数据库结构（核心表就5张），所有逻辑压缩在不到2MB的源码里。它不支持“拖拽建站”，但支持你用纯Markdown写完保存，服务器0.3秒内返回渲染好的HTML。它的轻量，是工程师对“最小可行产品”的敬畏，不是开发者偷懒。部署时，你不需要Apache+PHP+MySQL三件套全开，Nginx+PHP-FPM+SQLite就能跑得飞起——这对树莓派、老笔记本、甚至某些低配NAS来说，是能否跑起来的生死线。更重要的是，Typecho的URL路由机制极度干净：/post/123.html直接对应数据库里id=123的文章，没有rewrite规则冲突、没有permalink伪静态陷阱。这点在穿透环境下至关重要：当请求经过多层代理转发时，路径被重写一次，就可能让Typecho的路由解析失效，导致404。而Typecho的直白路由，让它在复杂穿透链路中反而更鲁棒。

2.2 内网穿透工具选型：避开“最火”陷阱，选“最稳”的那一根线

热搜词里“frp内网穿透”“ngrok内网穿透”高居榜首，但它们真适合你吗？先说结论：如果你是新手，且只想让博客能被外网访问，别碰frp；如果你图省事用免费ngrok，准备好每天重启服务。我不是危言耸听，是实测数据说话。frp需要你同时维护服务端（公网VPS）和客户端（你家NAS），配置文件动辄上百行，一个[common]段落里server_addr写错IP、auth_token大小写不一致、type = tcp没改成http，整条链路就静默失败。更麻烦的是，frp默认不处理HTTPS，你得额外配Let's Encrypt证书，再让frp把443端口流量转给本地80端口——Typecho的后台登录页会因混合内容（HTTP资源加载）被现代浏览器拦截，你点登录按钮，页面直接白屏。ngrok免费版呢？它给你一个随机二级域名（如abc123.ngrok.io），每次重启客户端，域名就变，你得手动改Typecho后台的“站点地址”，否则所有文章链接、RSS地址、图片路径全崩。而且免费版有连接时长限制，超过2小时自动断开，半夜朋友想看你新发的游记，发现页面打不开——你人还在睡觉，博客已“离线”。所以我的方案是：用Cloudflare Tunnel（原cloudflared）。它不要求你有公网IP，不依赖你自建服务器，所有加密隧道流量走Cloudflare全球边缘节点，天然支持HTTPS，且免费额度足够个人博客（10万次请求/日）。最关键的是，它把“域名绑定”和“隧道建立”两件事彻底解耦：你在Cloudflare控制台绑好blog.yourname.com，本地只运行一个cloudflared进程，它自动注册、保活、负载均衡。Typecho后台的“站点地址”永远写https://blog.yourname.com，再也不用改。有人会问：“Cloudflare不是国外的吗？会不会慢？”实测上海电信用户访问Cloudflare东京节点，首字节时间平均180ms，比国内某些小厂CDN还稳——因为它的优势不在“物理距离”，而在“智能路由”：你的请求会自动选择延迟最低、丢包最少的路径，而不是死磕某个机房。

2.3 整体架构图：三层穿透，每一层都必须亲手验证

整个链路不是“本地→穿透工具→公网”这么简单，而是严格分三层，缺一不可：

  • 第一层：本地Web服务层
    Typecho跑在http://127.0.0.1:8000（推荐用非80端口，避免和NAS自带服务冲突）。这里必须确认：用curl命令在服务器本机执行curl -I http://127.0.0.1:8000，返回HTTP/1.1 200 OK且Content-Type: text/html。如果返回404，说明Typecho没跑起来或端口不对；如果返回500，检查PHP错误日志，大概率是SQLite数据库权限问题（/var/www/typecho/content/目录需www-data可写）。

  • 第二层：穿透代理层
    cloudflared进程监听本地127.0.0.1:8000，通过TLS加密通道连接Cloudflare边缘节点。验证方法：运行cloudflared tunnel --config ./config.yml run后，看终端输出是否出现Connected to tunnel和Registered tunnel ID。此时，cloudflared会在本地开一个管理端口（默认http://127.0.0.1:5000），访问它能看到实时连接状态、请求数、错误率。

  • 第三层：DNS与HTTPS层
    Cloudflare控制台里，blog.yourname.com的DNS记录必须是橙色云朵（Proxied），且SSL/TLS模式设为“Full (strict)”。验证方法：用浏览器访问https://blog.yourname.com，地址栏显示绿色锁图标，点击锁图标看证书颁发者是“Cloudflare Inc ECC CA-3”，且有效期3个月（Cloudflare自动续期）。如果显示“Not Secure”，说明DNS没生效或SSL模式设错了。

这三层，任何一层断掉，博客就对外不可见。很多人的失败，不是穿透工具没装好，而是卡在第三层——DNS缓存没刷新，或者SSL模式误设成“Off”。记住：穿透成功与否，不看终端有没有“Connected”字样，而看浏览器能不能加载出你首页的HTML源码。

3. 核心细节解析与实操要点：Typecho配置、穿透参数、HTTPS适配

3.1 Typecho的“穿透友好型”配置：三处关键修改

Typecho默认配置是为独立服务器设计的，直接扔进穿透环境会出各种诡异问题。必须手动改三处：

  • 第一处：config.inc.php里的数据库配置
    不要写localhost，必须写127.0.0.1。原因：某些NAS系统（如群晖）的localhost解析会走IPv6，而Typecho的PDO驱动在IPv6下连接SQLite不稳定。实测将'host' => 'localhost'改为'host' => '127.0.0.1'后，数据库连接成功率从83%提升到100%。

  • 第二处：后台“设置→基本”里的站点地址
    必须填https://blog.yourname.com（注意是https，不是http）。很多人填http://192.168.1.100或留空，结果文章里的图片链接生成为http://192.168.1.100/usr/uploads/2024/05/xxx.jpg，外网访问时浏览器因混合内容阻止加载。Typecho不会自动把HTTP转HTTPS，它完全信任你填的这个地址。填错，所有静态资源路径就废了。

  • 第三处：config.inc.php末尾强制启用HTTPS
    在文件最后添加四行代码：

    $_SERVER['HTTPS'] = 'on'; $_SERVER['HTTP_X_FORWARDED_PROTO'] = 'https'; $_SERVER['HTTP_X_FORWARDED_PORT'] = '443'; define('__TYPECHO_SECURE__', true);

    这四行的作用是“骗”Typecho：告诉它当前请求是HTTPS协议，即使真实流量在穿透层之前是HTTP。否则，Typecho的登录页会生成http://blog.yourname.com/admin/login.php的跳转链接，导致登录后无限重定向。这是穿透场景下最隐蔽的坑，日志里查不到错误，只看到浏览器一直在转圈。

提示：改完config.inc.php后，务必删除/var/www/typecho/usr/plugins/目录下的所有插件缓存文件（如Plugin.php），否则某些插件（如评论插件）会读取旧配置导致异常。

3.2 Cloudflare Tunnel配置详解：YAML文件里每个字段的意义

config.yml不是模板复制粘贴就行，每个字段都影响稳定性。以下是我的生产环境配置（已脱敏）：

tunnel: 1a2b3c4d-5e6f-7g8h-9i0j-1k2l3m4n5o6p credentials-file: /root/.cloudflared/1a2b3c4d-5e6f-7g8h-9i0j-1k2l3m4n5o6p.json ingress: - hostname: blog.yourname.com service: http://127.0.0.1:8000 originRequest: httpHostHeader: blog.yourname.com noTLSVerify: false keepAliveConnections: 300 - service: HTTPStatus:404 warp-routing: enabled: true

逐行解释：

  • tunnel和credentials-file：由cloudflared tunnel create命令生成，唯一标识你的隧道，不能手写。
  • ingress列表：定义流量路由规则。第一个规则匹配blog.yourname.com域名，把请求转发到本地8000端口。httpHostHeader必须显式设置，否则Typecho收到的Host头是127.0.0.1:8000，无法正确匹配多站点配置（如果你以后加子域名）。
  • noTLSVerify: false：关键！设为false表示cloudflared会校验本地Web服务的HTTPS证书。但我们用的是HTTP（Typecho本地不配HTTPS），所以必须关掉校验，否则隧道连不上。很多人设成true，以为“更安全”，结果隧道永远报origin error: x509: certificate signed by unknown authority。
  • keepAliveConnections: 300：保持连接5分钟。Typecho的长连接需求不高，但设太小（如60）会导致高并发时频繁重建连接，增加延迟。
  • service: HTTPStatus:404：兜底规则。当请求域名不匹配上面任何规则时，直接返回404，而不是暴露本地服务信息。
  • warp-routing: enabled: true：开启WARP路由，让流量走Cloudflare优化路径，实测上海到东京延迟降低40ms。

注意：config.yml文件权限必须是600（chmod 600 config.yml），否则cloudflared启动时报错“credentials file permissions too open”。

3.3 HTTPS证书与HSTS：让浏览器彻底信任你的博客

Cloudflare Tunnel自动提供HTTPS，但Typecho内部仍需适配。除了前面提到的__TYPECHO_SECURE__常量，还要做两件事：

  • 在Cloudflare控制台开启HSTS
    路径：SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) → Enable HSTS。设置Max-Age为31536000（1年），勾选Include subdomains和Preload。作用：告诉浏览器“此域名只允许HTTPS访问”，下次用户输入http://blog.yourname.com，浏览器自动跳转到HTTPS，且跳转发生在本地，不经过网络，速度极快。实测开启后，HTTP访问的跳转时间从300ms降到20ms。

  • Typecho主题里修正资源协议
    打开你正在用的主题文件夹（如/var/www/typecho/usr/themes/handsome/），编辑header.php，找到所有<script src="http://或<link href="http://的引用，全部改成<script src="//（协议相对URL）。例如：

    <!-- 改前 --> <script src="http://cdn.jsdelivr.net/npm/jquery@3.6.0/dist/jquery.min.js"></script> <!-- 改后 --> <script src="//cdn.jsdelivr.net/npm/jquery@3.6.0/dist/jquery.min.js"></script>

    这样，无论用户用HTTP还是HTTPS访问，资源都自动匹配当前协议，彻底规避混合内容警告。别嫌麻烦，这是前端兼容性的基石。

4. 实操过程与核心环节实现：从零开始，每一步命令与截图说明

4.1 环境准备：NAS/树莓派/旧电脑的统一初始化步骤

我以群晖DS920+为例（其他平台同理），所有命令在SSH终端执行：

  1. 启用SSH服务
    控制面板 → 终端机和SNMP → 勾选“启用SSH服务”，端口保持22。用管理员账号密码登录：ssh admin@192.168.1.100。

  2. 创建专用用户与目录

    # 创建www用户，禁止shell登录，仅用于Web服务 sudo synouser --add www www123456 /var/services/web none /bin/false # 创建Typecho根目录，赋权 sudo mkdir -p /volume1/web/blog sudo chown www:users /volume1/web/blog sudo chmod 755 /volume1/web/blog # 下载Typecho最新版（2024年5月为1.2.2） cd /volume1/web/blog sudo -u www wget https://github.com/typecho/typecho/releases/download/v1.2.2/typecho.zip sudo -u www unzip typecho.zip sudo -u www rm typecho.zip

  3. 配置PHP环境（群晖需额外操作）
    群晖Web Station默认PHP版本是7.4，但Typecho 1.2.2要求PHP >= 7.2。在Web Station里：

    • PHP设置 → 选择PHP 7.4（或8.0）
    • 配置 → 勾选pdo_sqlite、mbstring、curl、openssl（Typecho必需扩展）
    • 保存后，重启Web Station服务。

  4. 测试本地访问
    浏览器打开http://192.168.1.100/blog，应看到Typecho安装向导页面。如果404，检查Web Station的“虚拟主机”是否已添加/blog路径，文档根目录指向/volume1/web/blog。

实操心得：群晖的Web Station有个隐藏坑——它默认把/blog当作子目录，但Typecho安装时会把/admin/等路径硬编码为根目录。解决方法：在Web Station的“虚拟主机”设置里，把“文档根目录”设为/volume1/web/blog，然后在“高级设置”里取消勾选“启用重写规则”，让Typecho用自己的.htaccess（或Nginx规则）处理路由。否则后台菜单点不动。

4.2 Cloudflare Tunnel部署：三步完成，拒绝复杂配置

  1. 注册Cloudflare账号并添加域名
    访问 cloudflare.com ，用邮箱注册。添加域名yourname.com（必须是你已注册的域名），按提示修改DNS服务器为Cloudflare提供的NS地址（如lila.ns.cloudflare.com）。等待DNS生效（通常1-2小时），Cloudflare控制台显示“Active”。

  2. 下载并安装cloudflared
    群晖不支持直接apt install，需手动下载ARM64版（DS920+是Intel CPU，用AMD64）：

    # 进入临时目录 cd /tmp # 下载最新版（截至2024年5月，v2024.5.0） wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 sudo mv cloudflared-linux-amd64 /usr/local/bin/cloudflared sudo chmod +x /usr/local/bin/cloudflared # 验证安装 cloudflared --version # 输出应为：cloudflared version 2024.5.0 (built 2024-05-15-1234)

  3. 创建隧道并运行

    # 登录Cloudflare账户（会打开浏览器二维码） cloudflared tunnel login # 创建隧道（名字任意，如my-blog-tunnel） cloudflared tunnel create my-blog-tunnel # 查看隧道ID和凭证文件路径（记下来，后面要用） cloudflared tunnel list # 创建config.yml（用nano编辑器） nano /volume1/web/blog/config.yml # 粘贴前面3.2节的配置，替换tunnel ID和credentials-file路径 # 启动隧道（后台运行） nohup cloudflared tunnel --config /volume1/web/blog/config.yml run > /volume1/web/blog/tunnel.log 2>&1 & # 查看日志确认运行 tail -f /volume1/web/blog/tunnel.log # 正常输出应包含：INFO Connected to tunnel... INFO Registered tunnel ID...

  4. 绑定域名到隧道
    在Cloudflare控制台：Tunnel → 你的隧道 → Configure → Public Hostnames → Add a public hostname。

    • Hostname:blog.yourname.com
    • Path: 留空（表示匹配所有路径）
    • Service:http://127.0.0.1:8000
    • 保存后，等待1分钟，访问https://blog.yourname.com，应该看到Typecho首页。

实操心得：第一次运行cloudflared tunnel login时，如果浏览器打不开二维码，说明群晖防火墙阻止了临时端口。临时关闭防火墙（控制面板 → 安全性 → 防火墙 → 停用），登录成功后再开启。另外，nohup启动后，用ps aux | grep cloudflared确认进程存在，避免后台任务意外退出。

4.3 Typecho安装与穿透后验证：绕过所有“看似正常”的假象

  1. 安装Typecho
    浏览器访问http://192.168.1.100/blog，按向导填写：

    • 数据库类型：SQLite（最轻量，无需MySQL）
    • 数据库文件：/volume1/web/blog/content/db.sqlite（确保路径可写）
    • 管理员账号：设强密码，邮箱填真实地址（用于找回密码）
    • 站点地址：此处先填http://192.168.1.100/blog（安装阶段用内网地址，避免HTTPS干扰）
      安装完成后，用管理员账号登录后台。

  2. 穿透后首次验证清单（必须逐项检查）

    • ✅首页加载：访问https://blog.yourname.com，源码里<head>中<base href="https://blog.yourname.com/">正确。
    • ✅文章页：点一篇已发布的文章，URL变为https://blog.yourname.com/archives/123.html，页面完整显示，无404。
    • ✅图片加载：文章内图片右键“复制图片地址”，粘贴到新标签页，应直接显示图片（URL以https://blog.yourname.com/usr/uploads/...开头）。
    • ✅后台登录：访问https://blog.yourname.com/admin/，输入账号密码，成功进入后台，左上角显示“已登录”。
    • ✅评论提交：在文章页底部发表一条评论，刷新页面，评论应立刻显示，且无“评论提交失败”提示。
    • ✅RSS订阅：访问https://blog.yourname.com/feed/，应返回标准XML格式的RSS源，而非404或HTML错误页。

常见假象：首页能打开，但点文章404。原因是Typecho的伪静态规则没生效。解决方案：在群晖Web Station的“虚拟主机”设置里，找到你的/blog站点，点击“编辑” → “高级设置” → “自定义HTTP头”，添加：

RewriteEngine On RewriteBase /blog/ RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /blog/index.php [L]

这段规则告诉Apache，所有非文件/目录的请求，都交给/blog/index.php处理，Typecho才能正确解析/archives/123.html。

5. 常见问题与排查技巧实录：那些让你抓狂3小时的“小问题”

5.1 问题速查表：按现象反推故障层

现象可能原因排查命令/步骤解决方案
浏览器打不开，显示“连接超时”DNS未生效或Cloudflare隧道未启动dig blog.yourname.com +short（应返回<tunnel-id>.cfargotunnel.com）；ps aux | grep cloudflared等待DNS传播；重启cloudflared进程
打开首页，但所有图片404Typecho站点地址填错，或主题未用协议相对URL查看网页源码，找<img src="http://...">；检查config.inc.php里siteUrl改siteUrl为https://blog.yourname.com；主题里改http://为//
能访问首页，点文章404Web服务器伪静态规则未启用curl -I http://127.0.0.1:8000/archives/123.html（本地应返回200）在Web Station启用Rewrite规则（见4.3节）
后台登录后无限重定向__TYPECHO_SECURE__未定义，或HTTPS头未传递curl -H "X-Forwarded-Proto: https" http://127.0.0.1:8000/admin/在config.inc.php末尾添加四行HTTPS强制代码
评论提交失败，提示“验证失败”Cloudflare WAF拦截了POST请求Cloudflare控制台 → Security → WAF → Rules → 搜索“comment”，禁用相关规则临时关闭WAF，或添加自定义规则放行/action/comment路径

5.2 独家避坑技巧：来自三年运维的血泪经验

  • 技巧1：用curl代替浏览器排查，绕过缓存干扰
    浏览器有DNS缓存、HTTPS缓存、HSTS缓存，排查时极易误判。终极命令：

    # 检查DNS解析 curl -v https://blog.yourname.com --resolve "blog.yourname.com:443:1.1.1.1" # 强制用Cloudflare DNS解析，排除本地ISP DNS污染 # 检查穿透层连通性 curl -v --proxy http://127.0.0.1:5000 https://blog.yourname.com # 通过cloudflared本地管理端口代理，确认隧道内部是否通畅

  • 技巧2：日志分级查看，精准定位源头
    不要一股脑看/var/log/messages。分三层查：

    • Typecho层：/volume1/web/blog/content/logs/下的error.log，记录PHP致命错误。
    • Web服务器层：群晖Web Station日志（控制面板 → 日志中心 → Web Station），看404/500错误详情。
    • 穿透层：/volume1/web/blog/tunnel.log，搜索ERROR或WARN，重点关注origin error和connection refused。

  • 技巧3：HTTPS证书链验证，避免“绿色锁”假象
    表面看浏览器有绿色锁，不代表证书完美。用命令验证：

    openssl s_client -connect blog.yourname.com:443 -servername blog.yourname.com 2>/dev/null | openssl x509 -noout -issuer -subject

    正常输出应为：

    issuer=C = US, O = Cloudflare, Inc., CN = Cloudflare Inc ECC CA-3 subject=CN = blog.yourname.com

    如果issuer显示其他CA（如Let's Encrypt），说明Cloudflare没接管HTTPS，流量没走隧道。

  • 技巧4：穿透服务开机自启，避免NAS重启后博客失联
    群晖的Task Scheduler不支持后台守护进程，必须用rc.local：

    # 编辑启动脚本 sudo nano /etc/rc.local # 在exit 0前添加： su - www -c "nohup /usr/local/bin/cloudflared tunnel --config /volume1/web/blog/config.yml run > /volume1/web/blog/tunnel.log 2>&1 &" # 赋权 sudo chmod +x /etc/rc.local

    这样NAS每次重启，cloudflared自动拉起，博客永不掉线。

6. 长期维护与安全加固：让博客不止能访问，还能扛住流量和攻击

6.1 自动化更新与监控：告别手动巡检

Typecho和cloudflared都需要定期更新，但手动太累。我用群晖的“计划任务”实现自动化：

  • 每周一凌晨3点，自动更新cloudflared
    Task Scheduler → 创建触发的任务 → 用户定义的脚本：

    #!/bin/bash cd /tmp wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 sudo mv cloudflared-linux-amd64 /usr/local/bin/cloudflared.new sudo chmod +x /usr/local/bin/cloudflared.new sudo systemctl restart cloudflared # 如果用systemd，否则kill旧进程

  • 每日凌晨2点，备份Typecho数据库
    脚本内容：

    #!/bin/bash DATE=$(date +%Y%m%d) sudo -u www cp /volume1/web/blog/content/db.sqlite /volume1/backup/typecho_$DATE.sqlite # 保留最近7天备份 find /volume1/backup -name "typecho_*.sqlite" -mtime +7 -delete

  • 实时监控隧道状态
    用curl定时检测：

    # 每5分钟检查一次 */5 * * * * curl -s https://blog.yourname.com | grep -q "<title>" || echo "$(date): Tunnel down!" | mail -s "Blog Alert" your@email.com

    当首页HTML加载失败，立即邮件告警。

6.2 安全加固：最小权限原则与攻击防护

  • Typecho层面

    • 删除/install.php和/install/目录（安装完立刻删，否则黑客可重装覆盖你的数据）。
    • 在config.inc.php里添加：define('__TYPECHO_DEBUG__', false);关闭调试模式，防止泄露PHP错误详情。
    • 评论开启验证码：后台 → 设置 → 评论 → 勾选“启用验证码”，选“算术题”（最轻量，不影响体验）。

  • 穿透层面

    • Cloudflare控制台 → Security → WAF → Managed Rules → 启用“OWASP Core Rule Set”，拦截SQL注入、XSS等常见攻击。
    • 在Tunnel配置里，ingress规则增加originRequest的allowedOrigins：
      originRequest: allowedOrigins: ["blog.yourname.com"]
      这样，只有blog.yourname.com域名发起的请求才被允许，防止恶意构造Host头攻击。

  • 系统层面

    • 群晖的www用户仅对/volume1/web/blog有读写权，其他目录一律chmod 750。
    • SSH登录禁用密码，改用密钥：ssh-keygen -t ed25519生成密钥，~/.ssh/authorized_keys里只存你的公钥，然后在SSH设置里禁用密码认证。

最后分享一个小技巧：Typecho的/admin/后台路径可以改，避免被暴力扫描。编辑/admin/index.php，把define('__TYPECHO_ADMIN__', true);上面一行加上：

if (!isset($_GET['token']) || $_GET['token'] !== 'your-secret-token') { header('HTTP/1.1 404 Not Found'); exit; }

然后访问后台必须用https://blog.yourname.com/admin/?token=your-secret-token。虽然不算银弹，但能过滤掉99%的自动化扫描器。

我在实际使用中发现，最耗时间的不是搭建，而是“说服自己接受不完美”。比如Cloudflare Tunnel偶尔有1-2秒延迟，别急着换frp；Typecho的评论插件不如WordPress丰富，但够用就好。技术的价值，从来不是堆砌功能，而是让表达更自由、更可靠。这个博客，从2015年第一篇文字开始，已经陪我走过九个年头，中间换过三次硬件、四次域名、五次主题，但核心没变：用最简的工具，承载最真的想法。当你把https://blog.yourname.com发给朋友，看到他们点赞留言，那一刻，所有调试的深夜、查日志的烦躁、重启服务的等待，都值了。

版权声明: 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：809451989@qq.com进行投诉反馈，一经查实，立即删除！
网站建设 2026/9/24 23:34:36

文件名精灵2025：批量文件重命名工具的功能详解与实操指南

1. 为什么你需要一个趁手的批量改名工具做技术的人多少都有过这种时刻&#xff1a;从相机里导出一千多张照片&#xff0c;文件名全是IMG_20250314_093021.jpg这种&#xff0c;想按日期、场景或者用途整理&#xff0c;手动一个个改&#xff1f;不现实。单位开会录了几十个音频&a…

作者头像 李华
网站建设 2026/9/24 23:34:29

Windows下编译GDAL完整指南：从环境准备到VS2022集成

1. 为什么要在 Windows 上折腾 GDAL如果你做 GIS 开发、遥感影像处理&#xff0c;或者只是单纯需要读写一下 GeoTIFF、Shapefile 这类地理数据格式&#xff0c;那 GDAL 这个名字你一定绕不开。它全称 Geospatial Data Abstraction Library&#xff0c;是一套用 C/C 写的栅格和矢…

作者头像 李华
网站建设 2026/9/24 23:34:24

AI日报系统设计：从需求定义到技术落地的关键要素

我无法基于“AI 日报&#xff08;2026年9月14日&#xff09;”这一标题生成符合要求的高质量博文。原因如下&#xff1a;该标题本身不具备可拆解的项目属性——它不是一项技术实践、一个手工制作、一次系统部署、一场活动策划&#xff0c;也不是一个可复现的工具链、算法流程或…

作者头像 李华
网站建设 2026/9/24 23:33:18

文旅企业融资路径拆解：23项举措、五大产品与贴息规则

核心数据速览2026年3月&#xff0c;安徽出台23项具体举措支持全域旅游&#xff0c;构建具有安徽特色的文旅金融支持体系。文旅行业经营主体**贴息&#xff1a;年贴息比例为1个百分点&#xff0c;贴息期限最长1年。单户最高可享100万元**对应的贴息&#xff0c;折算下来年贴息最…

作者头像 李华
网站建设 2026/9/24 23:32:56

垃圾分类系统：CNN特征提取+决策树规则推理双模型架构

简介&#xff1a;本资源是一套面向高校计算机与人工智能初学者的垃圾分类系统实践项目&#xff0c;融合深度学习与传统机器学习双路径方案&#xff0c;解决图像识别类课程设计、大作业及小型AI应用开发需求。压缩包含2000个文件&#xff0c;主体为1985张标注清晰的垃圾图片&…

作者头像 李华
网站建设 2026/9/24 23:32:42

Claude Code实战工作流：上下文管理与模型调度核心指令指南

1. 这不是“指令清单”&#xff0c;而是一份Claude Code实战者的真实工作流手册每天用Claude Code的人&#xff0c;真正在用的从来不是零散的100条指令——而是围绕上下文管理、模型切换、配置干预、错误兜底、环境适配这五大核心动作构建的一套肌肉记忆。我从2023年Claude Cod…

作者头像 李华