服务器与部署

分类下的全部文章

2025年12月6日9 分钟

Cloudflare证书

这篇笔记梳理 Cloudflare 场景下几类容易混淆的 TLS 证书及其通信方向：边缘证书部署在 Cloudflare CDN 边缘节点，负责浏览器到 Cloudflare 的 HTTPS 入口；源站证书安装在自有服务器上，负责 Cloudflare 回源到 Origin Server 时的加密与校验。文章用“用户→边缘→源站”的链路解释了边缘层的含义，并指出边缘证书带来的低延迟握手、缓存可用性、HTTPS 强制、HSTS、WAF 与规则处理等收益。配置部分区分了 Flexible、Full 和 Full strict：Flexible 只保证用户到 Cloudflare 加密，Full 回源使用 HTTPS 但不验证证书，Full strict 则会验证源站证书，通常适合配合 Cloudflare Origin Certificate 使用。需要注意的是，Origin Certificate 不是公共 CA 签发，只被 Cloudflare 信任，适合回源链路，不适合让浏览器或公网客户端直接访问。文章还拆分了两类“客户端证书”场景：Authenticated Origin Pulls 是 Cloudflare 向源站出示证书，由源站验证请求确实来自 Cloudflare，以降低绕过 CDN 直打源站的风险；访问者侧 mTLS 则要求 API 客户端或受限用户向 Cloudflare 提供客户端证书，用于管理后台、内部 API 等访问控制。整体适合正在配置 Cloudflare SSL/TLS、回源 HTTPS、源站防护或 mTLS 的站点维护者与后端/运维人员，用来建立证书类型、验证主体和部署位置之间的清晰对应关系。

服务器与部署

2025年12月6日16 分钟

cloudfare配置内网穿透

这篇记录围绕 Cloudflare Tunnel 搭建内网穿透展开，适用于希望把本地 FastAPI、管理后台或前端开发服务通过自有域名暴露到公网、但没有公网 IP 或不想做路由器端口映射的场景。流程从域名接入 Cloudflare 开始：先在原域名服务商关闭 DNSSEC，再把 NS 修改为 Cloudflare 提供的 Name Servers，并可用 dnschecker 检查 NS 是否已切换成功，因为 Cloudflare 的域名验证主要依赖 NS 接管而不是添加 TXT 记录。正文随后记录 cloudflared 的安装验证、tunnel login 授权、创建 tunnel，以及通过 config.yml 的 ingress 把 api、admin、web 等不同 hostname 映射到 localhost 的不同端口。一个 tunnel 可以承载多个服务，但每个 hostname 仍需分别创建 DNS 路由，既可在控制台添加 CNAME，也可用 cloudflared tunnel route dns 自动生成指向 cfargotunnel.com 的记录。文章还说明接入 Cloudflare 后 Universal SSL 会自动为域名签发并续期 HTTPS 证书，通常无需手动管理证书。排障部分强调 DNS 和隧道生效可能存在延迟，QUIC 连接失败多与 UDP 7844 被阻断有关，可改用 HTTP/2；若访问出现 502，则常见原因是本地目标服务未启动。最后补充了长期运行方式：cloudflared tunnel run 只是前台进程，生产或长期访问应改用系统服务或 nohup，并在修改 config.yml 后重启 cloudflared 才能让新配置生效。

服务器与部署

2025年12月6日2 分钟

picgo配置cloudflare-r2

这篇记录聚焦于用 PicGo 搭配 Cloudflare R2 搭建博客图床，并通过 Cloudflare 缓存规则改善图片访问速度。配置部分选择的是 wayjam 维护的 picgo-plugin-s3，而不是泛泛说明 S3 协议本身，核心操作是在 PicGo 插件市场安装对应版本后，按 R2/S3 存储参数完成上传配置。文章特别强调上传路径的命名方式，示例为 blog/img/{year}/{month}/{md5}-{timestamp}.{extName}，利用年份、月份、MD5、时间戳和扩展名组合，让对象路径尽量唯一，避免后续缓存命中与文件更新之间产生混淆。完成上传路径后，还需要设置 PicGo 的输出 URL，使上传后的图片能按自定义 CDN 域名路径被博客引用。后半部分转向 Cloudflare 后台的 Cache TTL 自定义规则，因为文件数量增多时每次加载可能变慢，作者通过匹配访问路径并设置缓存时间，让首次访问之后的图片加载更快。整体适合已经具备 PicGo、Cloudflare 域名和 R2 存储基础的用户参考，重点价值在于串起上传、URL 输出和边缘缓存三段链路，而不是从零解释 R2 或 S3 的所有概念。

服务器与部署

2025年12月6日6 分钟

minio配置

这份笔记面向 MinIO 对象存储的初始配置与公开读取场景，重点把控制台操作和 S3 客户端接入参数对应起来。创建本地用户时，user_name 可作为 MINIO_ACCESS_KEY，password 可作为 MINIO_SECRET_KEY，MINIO_ENDPOINT_URL 通常填写反向代理后的对象存储地址；如果直接用 IP 访问，则需要带上 9000 端口，区域在无特殊配置时可使用 auto。权限体系部分区分了 Users、Groups、OpenID 和 LDAP：本地用户适合直接分配 IAM policy，组用于批量继承权限，OpenID 适合接入 Keycloak、Auth0 等身份提供商实现 SSO，LDAP/AD 则便于复用企业账号和组映射。桶配置部分解释了 Custom Access Policy、服务器端加密、跨集群复制、对象锁、标签和配额等开关的含义，帮助判断哪些能力只是当前禁用，哪些需要按合规、同步或容量管理需求启用。公开文件读取策略示例只允许 GetBucketLocation 和 GetObject，并将对象资源限定在 public 桶下，同时明确不放行 ListBucket，避免匿名用户枚举桶内对象列表。适合正在把 MinIO 作为 S3 兼容存储接入应用、需要配置访问密钥、桶策略和基础权限边界的开发或运维人员参考。

服务器与部署

2025年12月6日8 分钟

给ip地址生成CA证书

这份配置记录面向没有域名、又希望在国内服务器上以 HTTPS 方式提供 DoH 入口的场景，核心做法是为公网 IP 生成包含 IP SAN 的自签证书，再由本地客户端手动信任或跳过校验，以避免使用容易受限的 UDP/TCP 明文 DNS。正文给出了 OpenSSL 命令，将证书和私钥放在 /etc/nginx/ip-ssl，并解释了 req -x509、-nodes、rsa:2048、有效期、CN 以及 subjectAltName=IP 的作用，其中 SAN 是让证书明确匹配 IP 的关键。文章同时区分了自签证书与受信 CA 证书：前者免费、快速、适合内网测试或可控客户端，但默认不被浏览器和系统信任；后者更适合公网正式生产环境，通常依赖域名验证。nginx 部分展示了监听自定义 HTTPS 端口并启用 HTTP/2，再把 /dns-query 反代到本机 AdGuard Home DoH 服务的配置，同时关闭后端证书校验。需要注意的是，外层客户端到 nginx 可以使用 HTTP/2，但 nginx 到 AdGuard Home 被强制为 HTTP/1.1，并清空 Connection 头，以规避后端 HTTP/2 兼容性、Keep-Alive 行为不一致导致的 EOF 或 TLS handshake error。最后还补充了 X-Real-IP、X-Forwarded-For 透传，以及在 AdGuardHome.yaml 的 http 段开启 x_forwarded_for，让后台显示真实客户端 IP 而不是 127.0.0.1。该记录适合自建 DNS、反代 AdGuard Home、需要理解 IP 自签证书边界的运维或后端开发者参考。

服务器与部署

2025年12月6日1 分钟

关于“服务器配置与部署”类别

“服务器配置与部署”类别应围绕服务器环境准备、服务上线、运行维护和相关配置规则建立清晰边界，帮助读者在浏览或归档时快速判断内容归属。该类别的核心价值不只是收纳文章，而是说明为什么需要单独设置这一分类、它承担什么用途，以及哪些问题不应混入开发实现、应用使用或其他主题中。内容范围可覆盖部署前后的环境配置、服务运行条件、运维规则、上线流程和与服务器管理直接相关的话题，但需要通过准则避免分类泛化。分类说明还应明确它与既有类别的差异，尤其是在文章同时涉及代码实现、工具使用或系统维护时，给出优先归类的判断依据。若站点已有相近分类，也需要评估是否保留独立类别、合并到其他类别，或拆分出更细的子类别。整体上，这一类别适合用于规范站点信息架构、减少文章归档混乱，并为后续服务器部署与维护类内容提供稳定的组织框架。