Jacin Blog

服务器与部署

分类下的全部文章

服务器与部署
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
服务器与部署
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
自建仓库Docker 源与部署
服务器与部署
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 分钟

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 时间指标的进一步诊断边界。

服务器与部署
1 分钟

nginx 配置密码

这份配置记录面向那些 Docker 镜像本身没有账号密码、但又不适合直接开放给公网访问的服务，核心思路是在端口暴露和反向代理两层同时收紧入口。服务侧先在 docker-compose 的 ports 中使用 127.0.0.1:3033:8081 这种绑定方式，让容器端口只接受本机访问，避免外部绕过 Nginx 直接连到后端。随后在服务器上安装 apache2-utils，并通过 htpasswd -c /etc/nginx/.htpasswd admin 创建基础认证所需的账号密码文件。Nginx 配置部分则是在对应的 location / 代理块中加入 auth_basic 和 auth_basic_user_file，前者开启浏览器弹窗式的 Basic Auth，后者指定刚生成的密码文件。完成修改后执行 systemctl reload nginx 重新加载配置，即可让访问该反向代理路径的用户先通过密码验证。它适合临时保护管理后台、自用工具或轻量服务，但前提是请求确实都经过 Nginx，且后端端口不要再以 0.0.0.0 形式暴露。

nginx
部署搭建discourse
服务器与部署
6 分钟

部署搭建discourse

这份记录聚焦在更换 VPS 后重新部署 Discourse 时，如何基于官方 discourse_docker 仓库重新生成环境，而不是直接搬迁旧目录。配置核心集中在 containers/app.yml：只启用 Web 与限流模板，将容器 80 端口绑定到本机 127.0.0.1:37880，便于前面再由 Nginx 做反向代理，同时用 DISCOURSE_HOSTNAME 指定对外域名。数据库与缓存被拆分处理，PostgreSQL 通过外部地址连接，Redis 则放在 Docker 内网中，Discourse 需要通过 docker_args 加入同一个 mynetwork，Redis 未设置密码时可仅依赖内网访问。邮件服务也是部署前提之一，需要提前准备 SMTP 地址、端口、用户名、密码和 STARTTLS，否则 Discourse 的注册、通知等基础功能会受影响。文章特别指出反代 HTTPS 场景下要设置 DISCOURSE_FORCE_HTTPS，让容器内部仍走 HTTP 时也能生成正确的 HTTPS 外链，避免站点链接或资源地址异常。最后通过 after_code hook 安装 PostgreSQL 16 客户端，并强制修正 pg_dump、psql 软链接，用来匹配外部数据库版本，适合已经熟悉 Docker、Nginx 和基础服务拆分部署的站点维护者参考。

谷歌免费GCP配置防火墙
服务器与部署
6 分钟

谷歌免费GCP配置防火墙

这篇记录聚焦 GCP 免费服务器启用后的两类容易被忽略的问题：免费额度相关扣费项检查，以及面向个人小服务场景的防火墙收紧。费用部分强调先确认是否存在 snapshots 快照，若有需到 disks 相关页面处理；同时检查磁盘类型、容量是否符合标准型 30GB 的免费配置，并留意实例区域选择，否则即使实例本身来自免费套餐，也可能因快照、磁盘或区域不匹配产生费用。网络策略上，作者采用较激进的最小暴露思路，入站只放行自己使用的三个 IP，其他访问全部禁止，且明确该机器只是挂载小服务，不承担代理用途。出站控制没有直接在 GCP 防火墙里细分，而是在实例内通过 ipset 与 iptables 建立 CUSTOM_OUT_BLOCK 链，将中国、澳大利亚以及 Cloudflare、Fastly、Akamai 等网段批量导入 out_block_list，并在 OUTPUT 链首匹配后丢弃。脚本执行前需要先借助其他节点代理完成下载，因为封锁列表来源本身可能依赖 CDN；运行后日志显示规则已挂载，并累计屏蔽约 26130 个出站网段。它更适合已经会使用 GCP 免费实例、希望减少误扣费并按个人访问范围加固服务器的用户参考，不应直接当作通用云防火墙模板套用。

gcp
3x-ui面板安装与使用
服务器与部署
15 分钟

3x-ui面板安装与使用

这篇记录围绕 3x-ui 面板的 Docker 部署与基础使用展开，目标是在服务器上快速搭建可管理 Trojan、SS 等入站节点的代理面板，并利用 3x-ui 查看流量使用情况。正文给出 docker-compose 配置示例，说明 host 网络模式、数据库与日志挂载、可选证书路径，以及 pull、down、up -d 等启动命令；由于新版不再直接在日志中输出管理账号信息，还演示了进入容器后安装 sqlite、apache2-utils，通过修改 x-ui.db 重置管理员用户名和密码，并用日志查看默认运行端口的做法。安全加固部分包括登录后修改语言、Web UI 监听端口和账号密码，也提供了可选的 Nginx HTTPS 反代配置，以及借助 Cloudflare 代理和防火墙规则限制面板访问来源的思路。节点配置部分分别展示 Trojan 入站、TLS、关闭 sniffing、提取 trojan:// 信息并转换为 Clash 配置的流程，SS 协议则以面板自动生成密码和常规入站配置为主。末尾对 Trojan、VLESS+TLS+WS、VLESS+TLS+Reality 在握手开销、传输封装、CPU 负载、DPI 难度、CDN/WAF 穿透、客户端支持和配置复杂度上作了对比，帮助已有服务器与 Docker 基础的读者在部署、加固和协议选择之间形成可执行判断。