25 篇
1 个三级分类
三级分类
技术笔记整理
技术体系化整理、工程实践与开发笔记。
专题分组
二级专题与三级分类
39 篇
2 个三级分类
19 篇
3 个三级分类
42 篇
2 个三级分类
12 篇
2 个三级分类
26 篇
3 个三级分类
1 篇
1 个三级分类
三级分类
当前页继续展示这个根分类下的全部文章；上面的二级专题和三级分类用于快速定位更细的主题入口。
1 分钟
Nginx 配置 非域名 443 端口的自签证书
这是一篇面向 Nginx HTTPS 默认入口的防探测配置笔记，目标是处理直接通过服务器 IP 访问 443 端口时可能暴露真实站点证书信息的问题。做法先使用 OpenSSL 生成一个有效期较长、CN 设置为 AccessDenied 的自签证书，并把生成的 fake.crt 与 fake.key 放到 Nginx 可读取的位置。随后在 default 配置中声明同时监听 80 和 443 的 default_server，用 server_name _ 承接未匹配到具体域名的请求，并将该默认虚拟主机绑定到这张“假证书”。这样扫描器或访问者如果不带正确域名访问 IP，在 TLS 阶段看到的不是生产站点证书，而是自签证书中的 AccessDenied；连接建立后，Nginx 再通过 return 444 直接断开请求。文章还给出一个验证思路：到 Censys 按 IP 搜索，检查公开扫描结果中是否仍能反查到真实域名。该配置适合希望降低证书透明度、互联网扫描或 IP 反查带来的域名暴露风险的运维与站点维护者，但它只针对默认入口和证书展示层面，不能替代完整的访问控制与资产隐藏策略。
nginx
2 分钟
Cursor 配置 Go debug 模式
这份速查记录聚焦在 Cursor 中为 Go 项目启用调试模式，配置入口是项目目录下的 .vscode/launch.json。正文给出两套可直接复制的 launch 配置：第一套使用 type 为 go、request 为 launch、mode 为 auto，并将 program 设置为 ${fileDirname}，适合从当前文件所在目录快速启动，也提示可改为 workspace 下的 main.go 或 cmd/server 等入口目录。第二套配置将 mode 显式改为 debug，以 ${workspaceFolder}/main.go 作为程序入口，同时设置 cwd、dlvToolPath、环境变量、showLog 和 verbose trace，便于在开发环境中固定调试参数并输出更详细的 Delve 日志。需要注意的是，示例里的 dlvToolPath 使用了本机绝对路径，迁移到其他机器或团队项目时应按实际安装位置调整；环境变量如 GIN_MODE、GOPROXY、GOEXPERIMENT 也应与项目运行要求匹配。它适合已经具备 Go、Cursor/VS Code Go 调试支持和 dlv 基础环境的开发者，用来快速搭建单入口项目或当前目录入口的调试配置。
1 分钟
Docker -pg 创建数据库
这则笔记记录了在 Docker 容器中直接维护 PostgreSQL 的两个常用操作：创建数据库和调整最大连接数。创建数据库部分使用 docker exec 进入正在运行的 my-postgres 容器，并通过 psql 指定用户、目标库和 -c 参数执行 CREATE DATABASE demo_db_for_gin，其中示例里的 super_postgres 需要替换成实际 PostgreSQL 用户名。连接数配置部分面向 docker-compose 场景，通过在服务配置中加入 command: postgres -c max_connections=1000，将 PostgreSQL 默认的 100 个连接提升到 1000。配置值并非固定推荐，需要结合机器资源和业务并发情况调整，避免只提高参数而忽略内存与连接管理成本。修改后可再次使用 docker exec 调用 psql，并执行 SHOW max_connections; 验证容器内 PostgreSQL 是否按预期加载新参数。整体适合作为容器化 PostgreSQL 日常初始化、临时建库和连接数参数核验的速查记录，尤其适合已经具备 Docker 与 psql 基础用法的开发或运维人员。
6 分钟
基于软链接的 nginx 管理 server 模块
这份笔记围绕 Nginx 多站点配置的模块化管理展开，核心做法是用软链接把“已编写的配置”和“当前生效的配置”分离。正文将 /etc/nginx/sites-available/ 定位为配置仓库，用来保存所有 server 文件、草稿、备份或暂时下线的网站；将 /etc/nginx/sites-enabled/ 作为实际加载目录，只放指向仓库文件的软链接，并通过 nginx.conf 在 http 段 include 该目录来决定哪些站点生效。文章给出了一份基础 nginx.conf 示例，包含事件连接数、日志、gzip、Keep-Alive、SSL 全局参数，以及同时加载 conf.d 和 sites-enabled 的关键配置。随后以一个 HTTPS 探针站点为例，展示 server 块如何配置证书、server_name、反向代理到 localhost:25774，并补充真实 IP、转发协议、WebSocket Upgrade、关闭代理缓冲和 50M 上传限制等常见代理设置。启用流程则被简化为脚本：使用 ln -sf 将 sites-available 下的配置批量链接到 sites-enabled，再执行 nginx -t 校验，通过后 reload 服务。它适合小型服务器或个人多站点环境，用较低成本实现站点配置的归档、迁移、批量启用和下线控制；需要注意的是，真正被 Nginx 读取的是 include 的 enabled 目录，单独把文件放进 available 并不会生效。
nginx
7 分钟
Nginx 配置防火墙
这篇笔记围绕 Nginx 在反向代理和 Cloudflare 接入场景下的访问控制配置展开，核心问题是如何在使用真实客户端 IP 的同时避免错误信任可伪造的请求头。文中先给出一种粗糙写法：在 server 中将 set_real_ip_from 设为 0.0.0.0/0，并通过 real_ip_header CF-Connecting-IP 改写 remote_addr，再配合 allow 与 deny all 做访问限制；但这种做法等于让任意来源都能提交 CF-Connecting-IP，攻击者可借此伪造来源地址。文章解释了 Nginx 默认情况下 remote_addr 代表 TCP 连接源 IP，未启用 real_ip 时相对可信，而一旦信任范围放得过宽，就会主动放弃这一安全边界。更稳妥的方案是从 Cloudflare 官方 IPv4、IPv6 地址接口拉取网段，生成 cloudflare_real_ip.conf，逐行写入 set_real_ip_from，并配置 real_ip_header 与 real_ip_recursive。随后可在 http 块全局 include，或在单个 server 块中按站点生效，更新脚本执行后通过 nginx -t 校验并 reload 服务。文中还提醒 allow 规则按顺序匹配，deny all 会直接拒绝并返回 403；如果 VPS 同时具备 IPv4 和 IPv6，放行列表也要同时覆盖两类地址。最后通过 crontab 每周自动刷新 Cloudflare 网段，适合需要在 Nginx、Cloudflare 和反向代理链路中正确处理真实 IP 与访问白名单的运维或后端开发者参考。
nginx
4 分钟
自建 Docker-代理镜像仓库(私有镜像托管)
这篇笔记聚焦 Docker 私有镜像仓库的 hosted/private 托管模式，说明它不是自动代理上游的缓存，而是需要用户或 CI/CD 主动把镜像搬运进去后才能供其他机器拉取。文章用 nginx:latest 迁移到 hub.jacin.me/library/nginx:latest 为例，给出 pull、tag、push 三步流程：先从 Docker Hub 拉取镜像，再改成本地私有仓库命名空间，最后推送到自建仓库。推送时出现 only the available single-platform image was pushed 的提示，是因为官方 nginx:latest 属于多架构镜像，但普通 docker pull 通常只下载当前机器 CPU 架构对应的版本，push 时私有仓库也只能保存本地已有的平台内容。对服务器、开发机和生产环境都统一使用 amd64 等同构场景来说，这通常不影响运行；但如果 amd64 VPS 推送后的镜像被 arm64 的 Mac M1/M2 或树莓派拉取，就可能遇到架构不匹配、exec format error 或找不到匹配架构的问题。文末通过表格区分代理模式和私有仓库模式：前者偏向 Docker Hub 等上游的加速与只读缓存，后者用于存储和分发自己构建的业务镜像，并且必须依赖 push 写入内容。它适合正在搭建内网镜像分发、理解多架构镜像行为，或在代理缓存与私有托管之间做选型的运维和后端开发者阅读。
服务器与部署10 分钟
自建仓库Docker 源与部署
这篇部署记录聚焦在自建私有 Docker Registry 的最小可用方案，将 registry:2 与 joxit/docker-registry-ui 通过 docker-compose 组合到同一个外部网络中运行，并把 Registry 数据持久化到本地目录。配置上的关键点是 Registry 只监听宿主机 127.0.0.1:5000，避免直接暴露服务，同时启用 REGISTRY_STORAGE_DELETE_ENABLED 以支持镜像删除；UI 则监听 127.0.0.1:18080，通过 NGINX_PROXY_PASS_URL=http://registry:5000 走容器内网代理，因此 Registry 侧不需要额外配置 CORS。外层 Nginx 分成两个 HTTPS 站点：一个面向 hub-ui.jacin.me 代理管理界面，一个面向 hub.jacin.me 代理仓库 API，并统一配置 Cloudflare 真实 IP、基础认证、转发头、长超时和 TLS 证书。仓库域名的 Nginx 配置额外设置 client_max_body_size 0，用于避免推送较大镜像层时被请求体大小限制拦截。验证部分使用一个基于 alpine:latest 的简单 Dockerfile 构建测试镜像，按 hub.jacin.me/test-project/hello-world:v1 的命名规则打标签，再通过 docker login 与 docker push 检查私有源是否可写。适合需要在个人服务器或小团队环境中快速搭建带 Web UI、HTTPS 入口、密码保护和删除能力的私有 Docker 镜像仓库的运维与后端开发者参考。
常规1 分钟
测试功能-test
该页面的正文内容只包含一张通过 Markdown 嵌入的图片，图片地址来自站点 CDN，并标注了 670×500 的显示尺寸。除图片资源本身外，正文没有提供文字说明、操作背景、测试目标、截图内容解读或任何可验证的技术结论，因此无法判断它是在测试图片上传、页面渲染、媒体展示，还是记录某个功能状态。现有信息只能确认页面具备展示单张图片的用途，不能支持读者提炼出教程步骤、配置方法、问题原因或观点判断。对于搜索、RSS 或文章卡片读者来说，这类内容的阅读价值主要停留在“查看图片是否能正常呈现”这一层面。若要形成更明确的技术导读，需要补充图片所表达的对象、测试场景、预期结果，以及与标题中“测试功能”相关的说明。当前摘要因此应保留边界感，避免把图片内容或作者意图解释成正文没有写出的信息。
1 分钟
vps 测试常用命令
这份笔记聚焦 VPS 基础测试中的两个常用场景：运行 NodeQuality（nq）做机器质量检测，以及用 curl 粗略观察访问链路耗时。由于 nq 测试相对吃内存，命令示例选择放到 nohup 后台执行，并把标准输出和错误输出统一写入 nq.log，避免 SSH 断开或终端关闭导致任务中断。文中给出两种交互输入处理方式：一种用 yes 持续自动确认，适合全部按确认推进；另一种先 echo y 确认启动，再用 yes n 对后续选项默认拒绝，便于减少不必要的交互选择。测速部分使用 curl -w 输出 DNS 解析、TCP 连接、TLS 握手、首包时间和总耗时，并通过 -o /dev/null 与 -s 去掉页面内容和进度信息，使结果更适合快速查看网络阶段耗时。它更像一份面向 VPS 初步体检的命令备忘，适合需要临时评估服务器质量、后台跑测试脚本或排查基础访问延迟的运维和个人站点维护者使用。需要注意的是，笔记只给出命令用法和日志落盘方式，并未展开解释 NodeQuality 各项评分含义或 curl 时间指标的进一步诊断边界。
Python 开发5 分钟
Cursor 配置 python debug 模式开发
从 PyCharm 迁移到 Cursor 调试 Python 项目时，最容易遇到的问题是模块导入路径不再由 IDE 自动补齐，导致运行当前文件时出现 ModuleNotFoundError。文章给出的常规做法是在项目下创建 .vscode/launch.json，配置 Python launch 任务，并通过 env 中的 PYTHONPATH: ${workspaceFolder} 手动把工作区加入模块搜索路径，相当于复刻 PyCharm 的 Mark Directory as Sources Root。它也解释了 Python 默认只会搜索标准库、site-packages 和当前脚本目录，因此在 VS Code/Cursor 这类编辑器中需要显式声明项目根路径。针对 conda 环境，文章进一步给出 settings.json 中固定 python.defaultInterpreterPath，以及 launch.json 中指定 python 解释器路径、保留 PYTHONPATH、设置 PYTHONUNBUFFERED=1 的配置方式，以便调试控制台正常输出日志。需要注意的是，Python Environment Manager 等环境管理插件可能在选择环境时自动重写 settings.json，与 launch.json 中的解释器配置冲突，并引发 permission denied，因此作者建议删除相关插件。整体适合正在从 PyCharm 转向 Cursor、希望降低内存占用但仍保留 Python 单文件调试和 conda 环境调试能力的开发者参考。