Chips

关于本站

这里是什么

一台自建服务器的运维笔记。内容基本来自实际问题:某条规则以为生效了其实没有、某个配置在重启后才暴露出来、某个"顺手加的"参数后来发现决定了整条链路的行为。

写下来的原因很实际——排查过的坑不值得排第二遍。如果这些记录对别人也有用,那更好。

写什么

主要围绕几条线:

不写什么

站点技术说明

这部分是可验证的,不是宣传语。可以自己查。

产物

纯静态 HTML + CSS。没有 JavaScript、没有外链字体、没有 CDN、没有统计代码、没有评论系统。

验证方式:打开任意页面 → view-source → 搜索 <script。只会看到 type="application/ld+json"(结构化数据,属 data block,不执行)。检查 <link><img> 的外部引用:

# 把页面里的所有外部引用列出来,正常结果是空
curl -s https://<本站>/ | grep -oE '(href|src)="https?://[^"]+"' | sort -u

响应头

Content-Security-Policy: default-src 'none'; style-src 'self'; img-src 'self';
  font-src 'self'; base-uri 'none'; form-action 'none'; frame-ancestors 'none'
Strict-Transport-Security: max-age=15552000
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
X-Frame-Options: DENY
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin
Permissions-Policy: accelerometer=(), camera=(), geolocation=(), ...

default-src 'none' 之所以成立,正是因为没有子资源需要放行。一旦引入任何第三方脚本或外链字体,CSP 就必须放宽——那不是配置问题,是取舍问题。详见为什么这个站没有 JavaScript

验证方式

curl -sI https://<本站>/ | grep -iE 'content-security|strict-transport|x-content-type'

服务端

也就是说:这台机器上公网能被访问到的,只有隧道转发的那几个虚拟主机名。

构建流程

Markdown → 静态 HTML,由一个单文件 Python 脚本完成。除 Markdown 渲染库外无依赖,不使用任何前端构建工具。

构建过程包含一步泄漏扫描:扫描全部产物,匹配内网 IP 段、UUID、密钥指纹、私有路径、备份目录名等模式;命中即中止构建,线上目录保持上一个正常版本不变。内容源文件另有一层更严的扫描。

这是为什么文章里的机器信息都是占位符——它是一条强制的自动化约束,而不是靠人工记得去删。

Favicon 与社交卡片由图标的 PNG 编码器在构建时直接生成(不依赖绘图库)。

缓存策略

HTML 缓存 5 分钟,样式表 URL 带内容哈希(?v=<hash>)故可长期缓存。这个设计的起因是一个真实故障:改了 CSS 但浏览器用缓存的旧样式渲染新 HTML,看起来像"改动没生效"。带哈希后,样式一变 URL 就变,不会再出现这种假故障。

订阅

没有邮件订阅,没有评论,没有账号。更新通过 RSSAtom 获取。也可以用全部文章页按年份翻。

联系

暂时没有公开联系方式。规范做法是放一份 security.txt——但本站在没有真实可达的安全联系邮箱之前不会放,因为一个填不出有效联系方式的 security.txt 比没有更糟(它声明了"可以联系我",实际却联系不上)。

若某篇内容有事实性错误,欢迎通过你能找到的任何渠道指出。错误被纠正比被忽略好,这一点比礼貌重要。