Posts on 小时候的胡同

使用两台 VPS 部署 TeslaMate

Sun, 10 May 2026 00:00:00 +0000

使用两台 VPS 部署 TeslaMate：Nginx HTTPS、Grafana 与 Tesla 中国 API 代理链路完整记录

为什么需要两台 VPS

正常情况下，TeslaMate 只需要一台 VPS 就可以部署：

TeslaMate + PostgreSQL + Grafana + Mosquitto + Nginx

但这次部署遇到的关键问题不是安装问题，而是网络出口问题。

主 VPS 上 TeslaMate 可以成功访问 Tesla 登录接口，并刷新 Token：

POST https://auth.tesla.cn/oauth2/v3/token -> 200
Refreshed api tokens

这说明 Tesla 账号 Token 本身是有效的，TeslaMate 也能正常启动。但主 VPS 访问 Tesla 中国区车辆接口时失败：

GET https://owner-api.vn.cloud.tesla.cn/api/1/products -> error: :timeout
Could not get vehicles: :timeout

手工测试也能复现：

curl -v --connect-timeout 15 https://owner-api.vn.cloud.tesla.cn/api/1/products

现象是 TCP 443 已经连上，但 TLS 握手超时：

Connected to owner-api.vn.cloud.tesla.cn port 443
TLS handshake, Client hello
SSL connection timeout

这说明问题不是 Docker、Nginx、Grafana、数据库，也不是 TeslaMate 配置错误，而是：

主 VPS 到 Tesla 中国 API 后端的网络链路不稳定或不可用

如果 TeslaMate 拿不到车辆列表，后续就会连锁出现：

TeslaMate 主页没有车辆
PostgreSQL 的 cars 表为空
Grafana 面板 No data
部分 Grafana SQL 面板因为车辆变量为空而报错

随后测试第二台 VPS，发现它可以正常访问 Tesla 中国 API：

curl -I --connect-timeout 10 https://fleet-api.prd.cn.vn.cloud.tesla.cn
curl -I --connect-timeout 10 https://owner-api.vn.cloud.tesla.cn/api/1/products

返回结果分别是：

HTTP/2 404
HTTP/2 401

这里的 404 和 401 都不是网络错误：

404 说明 Fleet API 根路径可达，只是根路径没有对应资源；
401 说明 Owner API 可达，只是没有携带 Tesla Token。

因此最终选择使用两台 VPS：

主 VPS：继续运行 TeslaMate、Grafana、Nginx、PostgreSQL
第二台 VPS：作为访问 Tesla 中国 API 的专用出口

这样做的目的不是“让整台主 VPS 都走代理”，而是只让 TeslaMate 容器访问 Tesla API 的 HTTPS 流量走第二台 VPS。其他服务，例如 Nginx、Grafana、sub-store、系统 apt、SSH 等，都保持原来的网络出口。

最终解决方案是：

第二台 VPS 上运行 tinyproxy
主 VPS 用 systemd 保持 SSH 隧道
主 VPS 用 redsocks 接收透明代理流量
主 VPS 用 iptables 只劫持 TeslaMate 容器的 443 流量

一、最终架构

本次使用两台服务器：

角色	IP	用途
主服务器 / Evoxt VPS	`<MAIN_VPS_IP>`	运行 TeslaMate、Grafana、PostgreSQL、Mosquitto、Nginx
代理出口服务器	`<PROXY_VPS_IP>`	运行 tinyproxy，帮助主服务器访问 Tesla 中国 API

域名规划：

域名	指向	用途
`<TESLAMATE_DOMAIN>`	`<MAIN_VPS_IP>`	TeslaMate Web
`<GRAFANA_DOMAIN>`	`<MAIN_VPS_IP>`	Grafana 仪表盘

最终流量路径：

浏览器
  ↓
https://<TESLAMATE_DOMAIN>
https://<GRAFANA_DOMAIN>
  ↓
Nginx + HTTPS + Basic Auth
  ↓
TeslaMate / Grafana

TeslaMate 访问 Tesla 中国 API 的路径：

TeslaMate 容器
  ↓
iptables 只劫持 TeslaMate 容器的 443 流量
  ↓
redsocks :12345
  ↓
Evoxt 本机 172.17.0.1:7890
  ↓
systemd 托管的 SSH 隧道
  ↓
<PROXY_VPS_IP>:127.0.0.1:8888
  ↓
tinyproxy
  ↓
Tesla 中国 API

这套结构的核心目标是：

只有 TeslaMate 容器访问 Tesla API 时走第二台服务器；
Evoxt 上的 Nginx、Grafana、PostgreSQL、Mosquitto、sub-store 等其他服务不走代理。

二、两台 VPS 之间是如何连接的

两台 VPS 之间不是直接把代理端口暴露到公网，而是通过 SSH 隧道连接。

设计原则：

第二台 VPS 的 tinyproxy 只监听 127.0.0.1:8888
主 VPS 通过 SSH 隧道把 172.17.0.1:7890 转发到第二台 VPS 的 127.0.0.1:8888
TeslaMate 容器的 443 流量被 iptables 转给 redsocks
redsocks 再通过 172.17.0.1:7890 进入 SSH 隧道

这样第二台 VPS 不会变成公开代理，主 VPS 的其他服务也不会被全局代理影响。

简化链路如下：

TeslaMate 容器
  ↓ iptables 只匹配 TeslaMate 容器 IP
redsocks :12345
  ↓
172.17.0.1:7890
  ↓ SSH 隧道
第二台 VPS 127.0.0.1:8888
  ↓ tinyproxy
Tesla 中国 API

三、部署 TeslaMate 主服务

1. 检查端口占用

主 VPS 上先检查 3000 和 4000 是否被占用：

ss -lntp | grep -E ':3000|:4000'

实际情况中，3000 已经被 sub-store 占用：

sub-store   xream/sub-store   0.0.0.0:3000->3000/tcp

所以不能让 Grafana 继续占用宿主机 3000。

最终端口规划：

服务	容器内部端口	宿主机端口
TeslaMate	`4000`	`127.0.0.1:14000`
Grafana	`3000`	`127.0.0.1:13000`
sub-store	`3000`	`0.0.0.0:3000`

2. 创建目录

mkdir -p /opt/teslamate
cd /opt/teslamate

3. 创建 `.env`

生成随机密钥：

openssl rand -hex 32
openssl rand -hex 24

创建 .env：

nano .env

内容示例：

TM_ENCRYPTION_KEY=替换成第一条随机字符串
TM_DB_USER=teslamate
TM_DB_PASS=替换成第二条随机字符串
TM_DB_NAME=teslamate

收紧权限：

chmod 600 .env

4. 创建 `docker-compose.yml`

nano docker-compose.yml

内容：

services:
  teslamate:
    image: teslamate/teslamate:latest
    restart: always
    depends_on:
      - database
      - mosquitto
    environment:
      - ENCRYPTION_KEY=${TM_ENCRYPTION_KEY}
      - DATABASE_USER=${TM_DB_USER}
      - DATABASE_PASS=${TM_DB_PASS}
      - DATABASE_NAME=${TM_DB_NAME}
      - DATABASE_HOST=database
      - MQTT_HOST=mosquitto
      - CHECK_ORIGIN=true
      - VIRTUAL_HOST=<TESLAMATE_DOMAIN>
      - TZ=Asia/Shanghai
    ports:
      - 127.0.0.1:14000:4000
    volumes:
      - ./import:/opt/app/import
    cap_drop:
      - all

  database:
    image: postgres:18-trixie
    restart: always
    environment:
      - POSTGRES_USER=${TM_DB_USER}
      - POSTGRES_PASSWORD=${TM_DB_PASS}
      - POSTGRES_DB=${TM_DB_NAME}
    volumes:
      - teslamate-db:/var/lib/postgresql

  grafana:
    image: teslamate/grafana:latest
    restart: always
    depends_on:
      - database
    environment:
      - DATABASE_USER=${TM_DB_USER}
      - DATABASE_PASS=${TM_DB_PASS}
      - DATABASE_NAME=${TM_DB_NAME}
      - DATABASE_HOST=database
      - GF_SERVER_DOMAIN=<GRAFANA_DOMAIN>
      - GF_SERVER_ROOT_URL=https://<GRAFANA_DOMAIN>/
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=${TM_DB_PASS}
      - GF_AUTH_ANONYMOUS_ENABLED=false
      - TZ=Asia/Shanghai
    ports:
      - 127.0.0.1:13000:3000
    volumes:
      - teslamate-grafana-data:/var/lib/grafana

  mosquitto:
    image: eclipse-mosquitto:2
    restart: always
    command: mosquitto -c /mosquitto-no-auth.conf
    volumes:
      - mosquitto-conf:/mosquitto/config
      - mosquitto-data:/mosquitto/data

volumes:
  teslamate-db:
  teslamate-grafana-data:
  mosquitto-conf:
  mosquitto-data:

检查配置：

docker compose config

启动：

docker compose up -d

检查容器：

docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}"

本机测试：

curl -I http://127.0.0.1:14000
curl -I http://127.0.0.1:13000

看到 302 Found 是正常的，表示服务已启动。

四、配置 Nginx 反向代理、HTTPS 与 Basic Auth

1. 创建 Basic Auth 密码

apt update
apt install -y apache2-utils
htpasswd -c /etc/nginx/.htpasswd-teslamate <BASIC_AUTH_USER>

2. 创建 Nginx 配置

nano /etc/nginx/sites-available/teslamate.conf

内容：

server {
    listen 80;
    server_name <TESLAMATE_DOMAIN>;

    location / {
        auth_basic "TeslaMate";
        auth_basic_user_file /etc/nginx/.htpasswd-teslamate;

        proxy_pass http://127.0.0.1:14000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

server {
    listen 80;
    server_name <GRAFANA_DOMAIN>;

    location / {
        auth_basic "Grafana";
        auth_basic_user_file /etc/nginx/.htpasswd-teslamate;

        proxy_pass http://127.0.0.1:13000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

启用配置：

ln -s /etc/nginx/sites-available/teslamate.conf /etc/nginx/sites-enabled/teslamate.conf
nginx -t
systemctl reload nginx

测试 Basic Auth：

curl -I -H "Host: <TESLAMATE_DOMAIN>" http://127.0.0.1
curl -I -H "Host: <GRAFANA_DOMAIN>" http://127.0.0.1

正常返回：

HTTP/1.1 401 Unauthorized

3. 申请 HTTPS 证书

先确认 DNS：

dig +short <TESLAMATE_DOMAIN>
dig +short <GRAFANA_DOMAIN>

应返回主 VPS IP：

<MAIN_VPS_IP>
<MAIN_VPS_IP>

申请证书：

certbot --nginx -d <TESLAMATE_DOMAIN> -d <GRAFANA_DOMAIN>

测试：

curl -I https://<TESLAMATE_DOMAIN>
curl -I https://<GRAFANA_DOMAIN>

正常返回 401 Unauthorized，表示 HTTPS 与 Basic Auth 都生效。

五、排查 TeslaMate 无车辆、Grafana No Data

安装完成后，TeslaMate 登录 Token 成功，但主页没有车辆，Grafana 显示 No data 或 SQL 错误。

查看日志：

cd /opt/teslamate
docker compose logs --tail=200 teslamate

关键日志：

POST https://auth.tesla.cn/oauth2/v3/token -> 200
Scheduling token refresh in 6 h
GET https://owner-api.vn.cloud.tesla.cn/api/1/products -> error: :timeout
Could not get vehicles: :timeout

这说明：

Token 成功；
车辆列表拉取失败；
数据库 cars 表为空；
Grafana 没有数据。

测试主 VPS 到 Tesla API：

curl -v --connect-timeout 15 https://owner-api.vn.cloud.tesla.cn/api/1/products
curl -v --connect-timeout 15 https://fleet-api.prd.cn.vn.cloud.tesla.cn

现象：

TCP 443 连接成功
TLS Client Hello 发出
SSL connection timeout

因此判断：主 VPS 到 Tesla 中国 API 的链路不正常。

六、在第二台 VPS 上安装 tinyproxy

第二台 VPS：<PROXY_VPS_IP>

1. 测试 Tesla API

curl -I --connect-timeout 10 https://fleet-api.prd.cn.vn.cloud.tesla.cn
curl -I --connect-timeout 10 https://owner-api.vn.cloud.tesla.cn/api/1/products

正常结果：

HTTP/2 404
HTTP/2 401

2. 安装 tinyproxy

apt update
apt install -y tinyproxy
cp /etc/tinyproxy/tinyproxy.conf /etc/tinyproxy/tinyproxy.conf.bak
nano /etc/tinyproxy/tinyproxy.conf

关键配置：

Port 8888
Listen 127.0.0.1
Allow 127.0.0.1

重启：

systemctl restart tinyproxy
systemctl enable tinyproxy
systemctl status tinyproxy --no-pager

检查监听：

ss -lntp | grep 8888

正常：

127.0.0.1:8888

测试代理：

curl -I -x http://127.0.0.1:8888 --connect-timeout 10 https://owner-api.vn.cloud.tesla.cn/api/1/products

正常：

HTTP/1.0 200 Connection established
HTTP/2 401

七、在主 VPS 上建立 SSH 隧道

主 VPS 需要通过 SSH 隧道访问第二台 VPS 的本地 tinyproxy。

1. 确认 Docker 网桥地址

ip -4 addr show docker0 | grep -oP '(?<=inet\s)\d+(\.\d+){3}'

结果：

172.17.0.1

2. 创建 SSH 密钥

在主 VPS 上执行：

ssh-keygen -t ed25519 -f /root/.ssh/teslamate_tunnel -N ""

查看公钥：

cat /root/.ssh/teslamate_tunnel.pub

把公钥加入第二台 VPS 的：

/root/.ssh/authorized_keys

权限：

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys

测试免密：

ssh -i /root/.ssh/teslamate_tunnel root@<PROXY_VPS_IP> "echo ok"

3. 用 systemd 托管 SSH 隧道

创建服务：

nano /etc/systemd/system/teslamate-proxy-tunnel.service

内容：

[Unit]
Description=TeslaMate SSH tunnel to <PROXY_VPS_IP> tinyproxy
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=root
ExecStart=/usr/bin/ssh -i /root/.ssh/teslamate_tunnel -N -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -o StrictHostKeyChecking=accept-new -L 172.17.0.1:7890:127.0.0.1:8888 root@<PROXY_VPS_IP>
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

启动：

systemctl daemon-reload
systemctl enable --now teslamate-proxy-tunnel

检查：

systemctl status teslamate-proxy-tunnel --no-pager
ss -lntp | grep 7890

正常：

Active: active (running)
172.17.0.1:7890

测试链路：

curl -I -x http://172.17.0.1:7890 --connect-timeout 10 https://owner-api.vn.cloud.tesla.cn/api/1/products

正常：

HTTP/1.0 200 Connection established
HTTP/2 401

八、为什么不能只给 TeslaMate 配 `HTTP_PROXY`

尝试在 docker-compose.yml 的 TeslaMate 服务里加入：

- HTTP_PROXY=http://172.17.0.1:7890
- HTTPS_PROXY=http://172.17.0.1:7890

但 TeslaMate 仍然请求失败：

GET https://owner-api.vn.cloud.tesla.cn/api/1/products -> error: :timeout

因此判断：TeslaMate 本体没有按预期使用这两个环境变量访问 Tesla API。

最终改用透明代理：

iptables 定向转发 TeslaMate 容器的 443 流量
  ↓
redsocks
  ↓
HTTP CONNECT 代理

九、配置 redsocks 透明代理

1. 安装 redsocks

在主 VPS 上执行：

apt update
apt install -y redsocks
cp /etc/redsocks.conf /etc/redsocks.conf.bak

2. 修改配置

nano /etc/redsocks.conf

内容：

base {
    log_debug = off;
    log_info = on;
    log = "syslog:daemon";
    daemon = on;
    redirector = iptables;
}

redsocks {
    local_ip = 0.0.0.0;
    local_port = 12345;

    ip = 172.17.0.1;
    port = 7890;

    type = http-connect;
}

启动：

systemctl restart redsocks
systemctl enable redsocks
systemctl status redsocks --no-pager

检查：

ss -lntp | grep 12345

正常：

0.0.0.0:12345

十、只劫持 TeslaMate 容器的 HTTPS 流量

1. 获取 TeslaMate 容器 IP

docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' teslamate-teslamate-1

示例：

172.18.0.4

2. 添加 iptables 规则

TM_IP=$(docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' teslamate-teslamate-1)

echo "TeslaMate container IP: $TM_IP"

iptables -t nat -N TESLAMATE_REDSOCKS 2>/dev/null || true
iptables -t nat -F TESLAMATE_REDSOCKS

iptables -t nat -A TESLAMATE_REDSOCKS -d 0.0.0.0/8 -j RETURN
iptables -t nat -A TESLAMATE_REDSOCKS -d 10.0.0.0/8 -j RETURN
iptables -t nat -A TESLAMATE_REDSOCKS -d 127.0.0.0/8 -j RETURN
iptables -t nat -A TESLAMATE_REDSOCKS -d 169.254.0.0/16 -j RETURN
iptables -t nat -A TESLAMATE_REDSOCKS -d 172.16.0.0/12 -j RETURN
iptables -t nat -A TESLAMATE_REDSOCKS -d 192.168.0.0/16 -j RETURN
iptables -t nat -A TESLAMATE_REDSOCKS -d 224.0.0.0/4 -j RETURN

iptables -t nat -A TESLAMATE_REDSOCKS -p tcp --dport 443 -j REDIRECT --to-ports 12345

iptables -t nat -D PREROUTING -s "$TM_IP" -p tcp --dport 443 -j TESLAMATE_REDSOCKS 2>/dev/null || true
iptables -t nat -A PREROUTING -s "$TM_IP" -p tcp --dport 443 -j TESLAMATE_REDSOCKS

解释：

只匹配来源为 TeslaMate 容器 IP 的 443 流量；
排除内网、Docker 网段、本机地址；
只把公网 HTTPS 流量转给 redsocks。

所以不会影响：

Nginx
Grafana
PostgreSQL
Mosquitto
sub-store
主机系统自身的 apt、curl、ssh

3. 检查规则

iptables -t nat -L PREROUTING -n -v --line-numbers | grep TESLAMATE
iptables -t nat -L TESLAMATE_REDSOCKS -n -v

应看到：

TESLAMATE_REDSOCKS  tcp  --  172.18.0.4  0.0.0.0/0  tcp dpt:443
REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 redir ports 12345

十一、重启 TeslaMate 并验证

cd /opt/teslamate
docker compose restart teslamate
docker compose logs --tail=200 teslamate

如果成功，之前的：

Could not get vehicles: :timeout

应该消失，TeslaMate 主页会显示车辆。之后 Grafana 中的 No data 也会随着数据采集逐步恢复。

十二、持久化与开机自启

1. 持久化 iptables

apt install -y iptables-persistent
netfilter-persistent save
systemctl enable netfilter-persistent

以后每次修改 iptables 后执行：

netfilter-persistent save

2. 确认服务开机自启

systemctl is-enabled teslamate-proxy-tunnel
systemctl is-enabled redsocks
systemctl is-enabled docker

应返回：

enabled

如未启用：

systemctl enable teslamate-proxy-tunnel
systemctl enable redsocks
systemctl enable docker

十三、常用排查命令

1. 检查 TeslaMate 日志

cd /opt/teslamate
docker compose logs --tail=100 teslamate

2. 检查 SSH 隧道

systemctl status teslamate-proxy-tunnel --no-pager
ss -lntp | grep 7890

3. 检查 tinyproxy 链路

curl -I -x http://172.17.0.1:7890 --connect-timeout 10 https://owner-api.vn.cloud.tesla.cn/api/1/products

正常：

HTTP/1.0 200 Connection established
HTTP/2 401

4. 检查 redsocks

systemctl status redsocks --no-pager
ss -lntp | grep 12345

5. 检查 iptables 计数

iptables -t nat -L TESLAMATE_REDSOCKS -n -v

如果 REDIRECT 行的 pkts/bytes 在增长，说明 TeslaMate 的 HTTPS 流量正在被透明代理接管。

6. 检查数据库是否已有车辆

cd /opt/teslamate
docker compose exec database psql -U teslamate -d teslamate -c "select id, eid, vid, name, model, inserted_at from cars;"

十四、安全注意事项

1. 不要直接开放 TeslaMate / Grafana 端口

不要使用：

ports:
  - 4000:4000
  - 3000:3000

应使用：

ports:
  - 127.0.0.1:14000:4000
  - 127.0.0.1:13000:3000

2. tinyproxy 不要监听公网

第二台服务器上的 tinyproxy 必须是：

127.0.0.1:8888

不要是：

0.0.0.0:8888

否则会变成公开代理。

3. Basic Auth 与 Grafana 密码要使用强密码

访问 Grafana 实际有两层认证：

第一层：Nginx Basic Auth
第二层：Grafana 登录

4. 不要使用公开免费代理

TeslaMate 涉及：

Tesla Token
车辆位置
行程
充电记录
电池信息

不要把这些流量交给来路不明的免费代理。

十五、总结

本次部署的关键不是 TeslaMate 安装，而是网络路径处理。

正常安装 TeslaMate 很简单：

Docker Compose + PostgreSQL + Grafana + Mosquitto

真正的问题是主 VPS 到 Tesla 中国 API 的 TLS 握手失败。解决方式是：

找一台能访问 Tesla 中国 API 的第二台 VPS；
在第二台 VPS 上运行 tinyproxy；
主 VPS 用 systemd 托管 SSH 隧道；
再用 redsocks + iptables 只透明代理 TeslaMate 容器的 443 流量。

最终实现：

TeslaMate 能访问 Tesla 中国 API；
Grafana 正常获取数据；
主 VPS 其他服务不走代理；
代理服务不暴露公网。

悲剧的4月18

Fri, 17 Apr 2026 12:00:00 +0800

今天本来只是一个再普通不过的工作日。

我随口问了一句：“你今天去打工吗？”
毕竟是周五，按惯例她要去餐馆做兼职。

没想到等来的，是一句——
“我摔倒了，在医院。”

其实，我并不是完全意外。
她每天魂不守舍，手机几乎从不离手，连骑车都在看屏幕。这样的状态，迟早会出事。

但讽刺的是，我每一次善意的提醒，换来的总是那句：
“你怎么什么都要管？”

接下来，是一连串忙碌而混乱的过程——检查、入院、签字。
医生说，颅内出血不多，在可控范围内；头部有轻微骨折。
需要住院15天，后期存在突发癫痫的可能。

我查了一下资料，这种概率应该不会超过2%。
但医生还是把最坏的情况全部讲了一遍。
中国的医生大概总是这样，把风险说尽，像是在提前撇清责任。

回家的路上，我忽然有些恍惚。

为什么我这一生，总是得不到一个“善良的结果”？

年轻时拼命工作，把自己交给公司，却从未被善待——
不是被边缘化，就是被迫离开，如今甚至还要承受老板的挤压。

感情也是如此。
从初恋到现在，我始终认真对待，却换来的，总是一地狼藉。

现在的婚姻，更像是一种无法摆脱的责任。
我承担着整个家庭的支出，连卫生、孩子的教育，也几乎是我一个人在扛。

我真的很累。

有时候，我甚至会想——
如果就这样离开这个世界，是不是下一世，会好一点？

2026 生产环境 NGINX 与 SSL 自动化最佳实践：从第一性原理到极致安全

Mon, 13 Apr 2026 20:15:00 +0800

一、引言：回归第一性原理

在处理复杂的 NGINX 配置和 SSL 证书申请之前，我们首先要问：为什么要这么做？

NGINX 的本质是“契约守门人”：它定义了外部不可信流量如何进入内部可信环境，承担了协议转换、负载均衡和安全屏障的角色。
SSL/TLS 的本质是“信任背书”：它解决了互联网通信中三个核心风险——窃听（加密）、篡改（完整性）和冒充（身份认证）。

二、 2026 年 Web 安全新局势

证书有效期缩短至 90 天：主流浏览器已全面强制执行短效证书。自动化不再是可选项，而是唯一的生存方式。
ECC (椭圆曲线加密) 成为绝对主流：256 位 ECC 密钥（如 Prime256v1）握手速度更快、CPU 占用更低。
HTTP/3 (QUIC) 标准化：基于 UDP 解决了 TCP 的队头阻塞问题，极大提升弱网加载速度。

三、 SSL 证书申请自动化方案：acme.sh

1. 安装 acme.sh

# 替换为你自己的邮箱，用于接收证书过期提醒
curl https://get.acme.sh | sh -s email=admin@yourdomain.com

# 使别名生效
source ~/.bashrc

2. 使用 DNS API 申请泛域名证书 (以 Cloudflare 为例)

# 1. 导入 API 密钥（从 DNS 服务商后台获取）
export CF_Key="your_global_api_key"
export CF_Email="your_email@example.com"

# 2. 申请 ECC 证书
# -d 指定域名，--keylength ec-256 指定使用 ECC 算法
acme.sh --issue --dns dns_cf \
    -d example.com \
    -d "*.example.com" \
    --keylength ec-256

四、 NGINX 极致安全配置模板

1. 规范化证书安装

使用 install-cert 命令，它会自动关联 NGINX 重载任务。

# 创建证书存放目录
mkdir -p /etc/nginx/ssl/example.com/

# 安装证书并设置自动重载
acme.sh --install-cert -d example.com --ecc \
    --key-file       /etc/nginx/ssl/example.com/key.pem \
    --fullchain-file /etc/nginx/ssl/example.com/cert.pem \
    --reloadcmd     "systemctl reload nginx"

2. NGINX 站点配置文件

路径： /etc/nginx/conf.d/example.com.conf

Nginx

# HTTP/3 & HTTPS 整合配置
server {
    # 监听配置
    listen 443 quic reuseport;       # HTTP/3 UDP 端口
    listen 443 ssl;                  # HTTP/1.1 & HTTP/2 TCP 端口
    listen [::]:443 ssl;             
    
    server_name example.com;

    # 证书路径
    ssl_certificate     /etc/nginx/ssl/example.com/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/example.com/key.pem;

    # 协议优化：仅使用 TLS 1.3 (2026年安全标准)
    ssl_protocols TLSv1.3;
    ssl_prefer_server_ciphers off;

    # 开启 HSTS (强制浏览器使用 HTTPS，有效期一年)
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    # 开启 HTTP/3 响应头 (告知浏览器支持 QUIC)
    add_header Alt-Svc 'h3=":443"; ma=86400';

    # 安全增强响应头
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-Content-Type-Options "nosniff";

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # 支持 WebSocket 协议
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

# 80 端口强制跳转 HTTPS
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

五、自动化运维：检查与验证

验证定时任务：确认 acme.sh 已自动写入 crontab（通常剩余 30 天自动续期）。
```
crontab -l | grep acme.sh
```

查看 NGINX 状态：

# 检查配置语法
nginx -t
# 平滑重载
systemctl reload nginx

安全评分：推荐使用 SSL Labs 进行扫描，此配置可稳拿 A+。

六、总结

在 2026 年，构建 Web 环境的公式是：ECC 证书 + acme.sh 自动化 + NGINX (TLS 1.3 & HTTP/3)。将底层的安全交付自动化，才能把精力留给更有价值的业务和生活。

Linux 运维核心指令集：从底层原理到实战进阶

Mon, 13 Apr 2026 18:30:00 +0800

Linux 运维核心指令集：从底层原理到实战进阶

在管理 VPS 或折腾 Docker 容器的过程中，Linux 命令行就是我们手中的手术刀。为了方便日常运维查阅，我将之前的几篇指令笔记进行了深度汇总与去重，并基于“第一性原理”重新梳理了底层的运行逻辑。

这篇文章将 21 个高频指令归纳为六大模块，旨在帮助大家从单纯的“复制粘贴”晋升为真正的“系统掌控者”。

一、基础导航与文件管理

这是与文件系统交互的起点，本质上是在操作文件系统的索引节点（inode）和目录项（dentry）。

1. `ls` (List) - 列出文件

原理：调用内核函数读取目录文件的内容（记录了文件名与 inode 的映射关系）。

常用命令：

ls -alh  # a:显示隐藏文件; l:详细列表; h:易读单位(KB/MB)

2. `cd` (Change Directory) - 切换目录

原理：更改当前 Shell 进程的工作目录环境变量 PWD。

常用命令：

cd /var/lib/docker  # 进入指定路径
cd ~                # 回到家目录
cd -                # 快速返回上一次所在的目录

3. `pwd` (Print Working Directory) - 确认坐标

原理：从根目录 / 开始向上追踪路径，确认当前进程的绝对位置。

常用命令：

pwd  # 在执行 rm 操作前，务必执行此命令确认位置

4. `mkdir` (Make Directory) - 创建新空间

原理：在文件系统中创建一个新的目录项，并分配 inode。

常用命令：

mkdir -p ./projects/hugo/posts  # -p 参数递归创建多层父目录

5. `rm` (Remove) - 慎用的“橡皮擦”

原理：解除文件名与 inode 的链接（unlink）。当链接数为 0 且无进程占用时，系统才会回收磁盘空间。

常用命令：

rm -rf /path/to/dir  # -r:递归; -f:强制。敲下前请三思！

6. `cp` & `mv` - 复制与移动

原理：cp 分配新 inode 并写入数据；mv 在同分区下仅修改目录索引，速度极快；跨分区则执行“复制+删除”。

常用命令：

cp -r /etc/nginx /etc/nginx_bak  # 递归备份配置文件夹
mv old.txt new.txt               # 重命名文件或移动位置

二、文本处理与内容查看

在 Linux 中，“一切皆文件”，处理配置文件和日志是运维的核心。

7. `cat` (Concatenate) - 快速预览

原理：将文件内容流化输出到标准输出（stdout），适合查看小文件。

常用命令：

cat /etc/os-release  # 查看系统发行版信息

8. `vim` / `vi` - 文本编辑神器

原理：全屏幕文本编辑器，分为命令模式、编辑模式和末行模式。

常用命令：

vim docker-compose.yml  # i 进入编辑；Esc 后输入 :wq 保存退出

9. `grep` (Global Regular Expression Print) - 关键词检索

原理：基于正则引擎扫描文本流，实时过滤并打印匹配行。

常用命令：

docker ps -a | grep memos  # 在容器列表中快速定位特定服务

10. `tail` - 追踪末尾

原理：基于文件描述符监听数据追加，是排查故障的“监视器”。

常用命令：

tail -f /var/log/nginx/error.log  # 实时滚动查看网站报错日志

三、权限与核心安全

权限管理控制着谁能读（r）、写（w）、执行（x），是系统的护城河。

11. `chmod` (Change Mode) - 权限赋能

原理：修改文件系统中的权限位。

常用命令：

chmod +x start.sh  # 给脚本增加执行权限
chmod 600 id_rsa   # 设置私钥仅本人可读写（SSH 安全要求）

12. `chown` (Change Owner) - 所属权变更

原理：修改文件的 UID（用户 ID）和 GID（组 ID）。

常用命令：

chown -R www-data:www-data /var/www/blog  # 解决网站 403 权限问题

13. `sudo` (Superuser Do) - 临时提权

原理：根据 /etc/sudoers 配置文件校验权限，以超级用户身份运行命令。

常用命令：

sudo apt update && sudo apt upgrade -y  # 以管理员权限更新系统

四、系统监控与健康检查

当服务器响应变慢或 Docker 容器崩溃时，这些指令能帮你快速定位瓶颈。

14. `df` & `du` - 磁盘侦察

原理：df 读取文件系统超级块信息；du 通过递归遍历统计具体目录占用。

常用命令：

df -h                     # 查看磁盘整体剩余空间
du -sh * | sort -hr       # 找出当前目录下最大的文件或文件夹

15. `top` / `htop` - 实时任务管理器

原理：从 /proc 虚拟文件系统中抓取进程运行状态的实时快照。

常用命令：

htop  # 交互式查看 CPU、内存、负载情况（推荐安装）

16. `free` - 内存深度扫描

原理：解析 /proc/meminfo，显示物理内存与 Swap 的使用详情。

常用命令：

free -m  # 以 MB 为单位查看内存压力

五、进程、网络与连接

掌控系统内部动态以及与外界的通信状态。

17. `ps` (Process Status) - 进程状态

原理：抓取瞬间的进程状态，适合配合 grep 使用。

常用命令：

ps -ef | grep portainer  # 获取特定服务的进程号 (PID)

18. `kill` - 终止进程

原理：向进程发送信号（SIGTERM 15 或 SIGKILL 9）。

常用命令：

kill -9 [PID]  # 强制关闭失去响应的进程

19. `curl` - 网络请求工具

原理：基于 libcurl 库，支持多种协议的数据传输和测试。

常用命令：

curl -I [https://laoqiao.life](https://laoqiao.life)  # 检查网站响应头和状态码

20. `ssh` (Secure Shell) - 远程之门

原理：基于非对称加密算法构建的安全传输协议。

常用命令：

ssh user@ip_address -p port  # 登录远程 VPS

六、备份与压缩

对于独立开发者来说，备份是所有操作中最重要的一环。

21. `tar` (Tape Archive) - 打包与压缩

原理：将多个文件归档为一个文件，并可调用 gzip 等算法进行压缩。

常用命令：

tar -zcvf backup.tar.gz /path/to/dir  # 压缩备份
tar -zxvf backup.tar.gz               # 解压到当前目录

结语

Linux 的强大之处不在于指令的数量，而在于组合的力量。当你能够熟练使用管道符 | 将这些基础工具串联起来解决复杂问题时，你就不再是命令的搬运工，而是这台机器的真正主人。

多实践、多“折腾”，肌肉记忆会比大脑更快记住这些符号。祝大家的博客和 VPS 运行稳定，永不宕机！

linux根目录文件夹说明

Sun, 22 Mar 2026 00:00:00 +0000

文件夹 / 文件	作用说明	重要程度
`/bin`	基础命令。存放系统最核心的二进制可执行命令（如 `ls`, `cp`, `cat`）。	⭐⭐⭐⭐⭐
`/boot`	引导目录。存放启动 Linux 时必需的文件，包括内核和引导加载程序。	⭐⭐⭐⭐
`/dev`	设备文件。Linux 把硬件也当做文件，这里存放硬盘、键盘、串口等映射文件。	⭐⭐⭐⭐
`/etc`	配置中心。极其重要，系统及所有软件的配置文件都在这里。	⭐⭐⭐⭐⭐
`/home`	普通用户家目录。每创建一个新用户，这里就会多一个以用户名命名的文件夹。	⭐⭐⭐
`/lib` & `/lib64`	系统库文件。存放程序运行所需的共享库（类似于 Windows 的 .dll 文件）。	⭐⭐⭐⭐
`/media` & `/mnt`	挂载点。通常用于挂载 U 盘、光驱或临时挂载其他硬盘分区。	⭐⭐
`/opt`	可选目录。存放第三方大型软件，很多一键安装脚本会把程序塞这里。	⭐⭐⭐
`/proc`	进程信息。虚拟文件系统，实时反映内核和进程的状态，不占硬盘空间。	⭐⭐⭐⭐
`/root`	管理员家目录。超级管理员 root 的私地（你的 Memos 数据就在这里）。	⭐⭐⭐⭐⭐
`/run`	运行数据。存放系统启动以来的临时运行信息（如进程 ID 文件）。	⭐⭐⭐
`/sbin`	管理员命令。存放只有 root 权限才能运行的系统管理命令。	⭐⭐⭐⭐
`/srv`	服务数据。存放某些服务（如 Web、FTP）启动后需要访问的数据。	⭐⭐
`/sys`	内核设备树。虚拟文件系统，提供比 `/proc` 更深层的硬件和驱动信息。	⭐⭐⭐
`/tmp`	临时文件夹。存放程序产生的临时数据，系统重启通常会清理这里。	⭐⭐⭐
`/usr`	用户程序。系统最大的目录，存放绝大多数安装的软件、库文件和文档。	⭐⭐⭐⭐⭐
`/var`	动态数据。存放经常变动的文件，如系统日志（log）、缓存、数据库。	⭐⭐⭐⭐⭐
`/lost+found`	碎片恢复。当文件系统非法关机损坏后，修复时找回的碎片会放在这。	⭐

从零打造私人云中枢：N150 + Debian + Cloudflare 内网穿透实战全记录

Sat, 14 Mar 2026 12:00:00 +0800

前言

为了实现数据自主和随时随地的远程办公，我利用一台 N150 (8G RAM) 小主机，搭建了以 Debian Server 为核心的家庭私有云。本文记录了从系统安装到实现全球无感访问的全过程。

1. 基础设施搭建：Debian 与 Docker

第一步是夯实地基。选择 Debian 服务器版是为了极致的稳定与轻量。

系统环境：Debian Server
内网 IP：**
核心工具：安装 Docker 与 Docker Compose，作为所有服务的运行容器。

2. 网络优化：Mihomo (Clash) 的深度调优

在家庭网络环境中，N150 同时承担了流量导流的任务。我们使用了 Mihomo 内核，但在配置过程中遇到了一个经典坑位：内网穿透流量被代理劫持。

关键突破：配置直连规则

为了防止 Cloudflare Tunnel 的流量被 Mihomo 误拦截导致连接失败（出现 198.18.x.x 虚拟 IP 报错），我们在 /etc/clashctl/resources/runtime.yaml 的 rules 最上方加入了强制直连规则：

YAML

rules:
  - DOMAIN-SUFFIX,cloudflare.com,DIRECT
  - DOMAIN-SUFFIX,argotunnel.com,DIRECT
  - DOMAIN-KEYWORD,cloudflared,DIRECT

经验总结：修改配置后务必重启 mihomo.service，确保规则生效。

3. 全球访问：Cloudflare Tunnel 隧道打通

在没有公网 IP 的环境下，Cloudflare Tunnel 是目前最优雅的内网穿透方案。

核心步骤：

安装与注册：将 cloudflared 安装为系统服务。
协议优化：针对国内网络环境，强制使用 --protocol http2。
绕过拦截：通过设置 export TUNNEL_DNS_UPSTREAM=https://223.5.5.5/dns-query，确保隧道建立时不被本地 DNS 污染干扰。

最终效果：

通过 laoqiao.life 域名，实现了外网 HTTPS 安全访问家中的 CasaOS 管理面板。

4. 私有同步桥梁：WebDAV 服务的部署

为了让笔记本软件（如 Tabby、Obsidian）能够实时同步数据，我们部署了轻量级的 WebDAV 服务。

Docker Compose 配置示例：

YAML

services:
  webdav:
    image: bytemark/webdav
    container_name: webdav
    restart: always
    ports:
      - "8080:80"
    environment:
      - AUTH_TYPE=Basic # 兼容性最好的验证方式
      - USERNAME=peter
      - PASSWORD=your_password
    volumes:
      - ./data:/var/lib/dav

实战笔记：在配置 Tabby 同步插件时，务必使用 Basic 验证模式，并确保 Cloudflare 端的 Public Hostname 正确指向了 **:8080 端口。

5. 成果展示与未来规划

目前，这台 N150 已经实现了：

CasaOS 全球远程管理。
Tabby 终端 跨设备自动同步配置。
WebDAV 作为笔记和文件的存储后端。

下一步计划：

部署 Immich 管理胶片摄影作品。
编写 Python 脚本实现 A 股与黄金数据 的自动化采集与展示。

从零开始：手把手教你用 GitHub 免费部署 Hugo 博客

Tue, 03 Mar 2026 12:00:00 +0800

嘿！想拥有一个既极速又极简，还完全免费的个人博客吗？

很多小伙伴被“部署”、“服务器”、“域名”这些词吓到了。其实，利用 Hugo（世界上最快的静态网站生成器） 和 GitHub（全球最大的代码托管平台），你只需要动动手指，就能拥有一个专属的互联网小家。

今天这篇教程，就是专门为“小白”准备的避坑指南。

一、为什么选择 Hugo + GitHub？

快： Hugo 生成页面的速度是以“毫秒”计算的。
省： GitHub Pages 提供的托管服务完全免费，连服务器钱都省了。
稳：只要 GitHub 不倒闭，你的博客就永远在线。
酷：纯文本写作，像程序员一样记录生活。

二、准备工作（你需要准备什么）

在开始之前，请确保你已经：

注册了一个 GitHub 账号。
在电脑上安装了 Git 和 Hugo（如果还没装，可以去官网下载，一路“下一步”即可）。

三、实战步骤

1. 本地创建博客

打开终端（Windows 的 PowerShell 或 Mac 的 Terminal），输入：

hugo new site my-blog
cd my-blog

2. 挑选一个“皮肤”（主题）

没有皮肤的博客是不完整的。我们以经典的 PaperMod 为例：

git init
git submodule add --depth=1 [https://github.com/adityatelange/hugo-PaperMod.git](https://github.com/adityatelange/hugo-PaperMod.git) themes/PaperMod
echo "theme = 'PaperMod'" >> hugo.toml

3. 写下第一篇文章

hugo new posts/hello-world.md

打开生成的 content/posts/hello-world.md，随便写点什么。

4. 推送到 GitHub

这是最关键的一步。

在 GitHub 上新建一个仓库，名字叫：你的用户名.github.io（例如 zhangsan.github.io）。
在本地博客根目录，关联这个仓库并推送：

git commit -m "初次建站"
git branch -M main
git remote add origin [https://github.com/你的用户名/你的用户名.github.io.git](https://github.com/你的用户名/你的用户名.github.io.git)
git push -u origin main

5.开启自动化部署（GitHub Actions）

现在最流行的做法是使用 GitHub Actions。你只需要在 GitHub 仓库的设置（Settings -> Pages）里，把 Build and deployment 的源改为 GitHub Actions。

GitHub 会自动识别 Hugo 项目并帮你把网页“变”出来。几分钟后，访问 https://你的用户名.github.io，奇迹就发生了！

四、掌握写作利器：Markdown (MD)

既然用了 Hugo，你就必须学会用 Markdown 写作。这是一种“所见即所得”的轻量级标记语言。

为什么大家都爱 Markdown？专注于文字：你不需要纠结字体大小、行间距，写完即排版。

跨平台：任何编辑器都能打开，不会像 Word 文档那样格式错乱。

代码友好：插入代码块非常漂亮，适合技术人。

常用命令“小抄” 如果你是第一次使用，记住下面这几个就够用了：

效果	Markdown 语法
一级标题	`# 标题名字`
二级标题	`## 标题名字`
加粗	`这是粗体`
斜体	`这是斜体`
超链接	`[文字](链接地址)`
插入图片	`![描述](图片地址)`
无序列表	`* 列表项`
引用代码	`代码内容`

温馨提示： 在 Markdown 中，所有的符号（如 #、*、!）后面都要加一个空格，这样格式才最标准。

五、结语

搭建博客只是第一步，持续的输出才是灵魂。

利用 Hugo，你可以摆脱社交平台的束缚，拥有一个完全属于自己的思考空间。

观尘：苦灭

Sat, 28 Feb 2026 00:00:00 +0000

《观尘：苦灭》

万象如泡影，浮生一刹那。执迷因爱起，烦恼自萌芽。

心被尘缘锁，身随幻境斜。观空知妄相，听雪落残花。

贪嗔如旧梦，痴怨付流沙。熄灭无明火，归来煮晚茶。

不寻来处路，此地即归家。

行旅江西：赣江、晒秋与古镇精致

Mon, 23 Feb 2026 01:00:00 +0800

每年的行旅依然继续。总觉得2025年过得极快，不知是年岁增长带来的时光流转，还是终日忙碌忘却了日月盈仄，一转眼便已是从年头到年尾。

今年，我将目光锁定在了从未涉足的省份——江西，主要游历了南昌、婺源与景德镇三处。

坦白讲，此前我对江西这个省份较为陌生。唯一与我有交集的，便是我所从事的有机硅行业——国内星火集团总部坐落于此。除此以外，即便是提及景德镇，平日里也不会常挂在嘴边。

然而，此行江西，却带给我一场深深震撼心灵的体验。赣江的宽广辽阔、景德镇的精致古朴、婺源徽派建筑的宁静优雅，均深深镌刻进我的脑海。

我想，我还会继续造访江西，去进行一次深度的体验。

赣江夜景

赣江之上，货船缓缓而行，粼粼波光映衬着繁华都市背后的辛勤劳作。

“无语佛”的震撼

这尊静立的佛像，有一种直抵人心的宁静力量。

婺源与篁岭晒秋

在婺源，晒秋不仅仅是一种农事景观，更是一幅充满生机的乡村画卷。

未及盛开的油菜花

虽然错过了漫山金黄，但初生的梯田绿意，依然诉说着新春的信息。

景德镇的极致

景德镇的美，的确并非几张照片或寥寥数语所能尽述。这虽是一个小镇，却值得你在这里驻足，静下心来，用心去感知、用眼去捕捉、用手去触碰，在那宁静中，体会那份经久不衰的精致与韵味。

鄱阳湖日落

鄱阳湖的落日，苍茫而壮阔，为这趟旅程画上了完美的句号。

以此篇行旅日记，开启我的2026吧。

2026-02-15日记

Sun, 15 Feb 2026 00:00:00 +0000

新春除夕前一天，日子非常的无聊。

孩子在自己房间享受珍贵的假期，打游戏和同学的连麦呼喊声，此起彼伏。

我自己坐在电脑前，无聊的开打B站，听着八百年前的音乐无限循环。翻动着Steam，看着仓库中丰富的游戏，还有可怜的游戏时间。我好像电子阳痿了，打游戏已经提不起不任何兴趣了，最喜欢的策略类游戏，长篇的文字说明让我很是烦躁，没有兴趣读下去。花了几十块买了2个游戏，发现不适合我，进去放仓库吧。

感觉我掉进了一种怪圈，消费好像能让我多巴胺分泌，刺激自己的大脑，但是消费后的空虚，却让我调入无尽的烦躁。

想起来一句诗词：

《元日》 [宋] 王安石爆竹声中一岁除，春风送暖入屠苏。千门万户曈曈日，总把新桃换旧符。

现在已经连烟花爆竹都不允许放了，真是可悲啊。春节的意义已经不存在了，在这个社会上，每个人就像流水线上的机器手，工作、消费、纳税、休息，最终进入医院把积蓄花光，死亡。

人生真的是无意义啊。

胶片相机

Sun, 08 Feb 2026 00:00:00 +0000

心中一直有个胶片梦，在购物车里反复掂量了许久。

最终，我并没有带走心心念念的徕卡 M6，而是选择了这台尼康大F。坦白说，预算是现实的考量，但更多的是一份对未知的敬畏——面对胶片拍摄的门槛，我尚无十足把握将这份重金投入在徕卡上。

但我对胶片的迷恋从未减退。无论是负片的宽容、正片的绚烂，还是黑白胶盐间的颗粒感，那种色彩的质感始终令我着迷。

更重要的是，我厌倦了数码时代那种“机关枪式”的快门倾泄。当摄影被海量的废片和无尽的后期填满，这项本该优雅、慢节奏的爱好，变得愈发仓促而逼仄。

爱好理应是生活的留白。唯有慢下来，去感受机械快门的每一次跳动，去等待显影液里的惊喜，才能真正触达摄影带来的精神愉悦。

2026年2月，落笔。

2026年上海的第一场雪

Sun, 25 Jan 2026 00:00:00 +0000

这组理光 GR4 记录的纪实片段，精准捕捉到了冬日都市中那份静谧且略带疏离的质感。从深夜街头那抹孤寂的暖黄灯影，到建筑墙面上利落的几何线条，理光直出的影调将平凡的物象点缀出了浓郁的故事感。画面中无论是粗糙的砖石纹理，还是光影交错下的空间结构，都展现出一种极简而有力的视觉语言。这些瞬间不需要繁杂的叙述，仅靠镜头对光线的细腻裁切，便勾勒出了城市角落里最真实、最动人的肌理，让人在冷暖对比的色调中感受到一种沉静的叙事力量。

近期照片

Sat, 24 Jan 2026 00:00:00 +0000

既然开了新的博客，就把自己近期的户外拍摄吧。当然，现在北方的天气很差，鸟的种类也不是很多，这篇文章，只是作为MD博客的练手

Posts on 小时候的胡同

使用两台 VPS 部署 TeslaMate

使用两台 VPS 部署 TeslaMate：Nginx HTTPS、Grafana 与 Tesla 中国 API 代理链路完整记录

为什么需要两台 VPS

一、最终架构

二、两台 VPS 之间是如何连接的

三、部署 TeslaMate 主服务

1. 检查端口占用

2. 创建目录

3. 创建 .env

4. 创建 docker-compose.yml

四、配置 Nginx 反向代理、HTTPS 与 Basic Auth

1. 创建 Basic Auth 密码

2. 创建 Nginx 配置

3. 申请 HTTPS 证书

五、排查 TeslaMate 无车辆、Grafana No Data

六、在第二台 VPS 上安装 tinyproxy

1. 测试 Tesla API

2. 安装 tinyproxy

七、在主 VPS 上建立 SSH 隧道

1. 确认 Docker 网桥地址

2. 创建 SSH 密钥

3. 用 systemd 托管 SSH 隧道

八、为什么不能只给 TeslaMate 配 HTTP_PROXY

九、配置 redsocks 透明代理

1. 安装 redsocks

2. 修改配置

十、只劫持 TeslaMate 容器的 HTTPS 流量

1. 获取 TeslaMate 容器 IP

2. 添加 iptables 规则

3. 检查规则

十一、重启 TeslaMate 并验证

十二、持久化与开机自启

1. 持久化 iptables

2. 确认服务开机自启

十三、常用排查命令

1. 检查 TeslaMate 日志

2. 检查 SSH 隧道

3. 检查 tinyproxy 链路

4. 检查 redsocks

5. 检查 iptables 计数

6. 检查数据库是否已有车辆

十四、安全注意事项

1. 不要直接开放 TeslaMate / Grafana 端口

2. tinyproxy 不要监听公网

3. Basic Auth 与 Grafana 密码要使用强密码

4. 不要使用公开免费代理

十五、总结

悲剧的4月18

2026 生产环境 NGINX 与 SSL 自动化最佳实践：从第一性原理到极致安全

一、 引言：回归第一性原理

二、 2026 年 Web 安全新局势

三、 SSL 证书申请自动化方案：acme.sh

1. 安装 acme.sh

2. 使用 DNS API 申请泛域名证书 (以 Cloudflare 为例)

四、 NGINX 极致安全配置模板

1. 规范化证书安装

2. NGINX 站点配置文件

五、 自动化运维：检查与验证

六、 总结

Linux 运维核心指令集：从底层原理到实战进阶

Linux 运维核心指令集：从底层原理到实战进阶

一、 基础导航与文件管理

1. ls (List) - 列出文件

2. cd (Change Directory) - 切换目录

3. pwd (Print Working Directory) - 确认坐标

4. mkdir (Make Directory) - 创建新空间

5. rm (Remove) - 慎用的“橡皮擦”

6. cp & mv - 复制与移动

二、 文本处理与内容查看

7. cat (Concatenate) - 快速预览

8. vim / vi - 文本编辑神器

9. grep (Global Regular Expression Print) - 关键词检索

10. tail - 追踪末尾

三、 权限与核心安全

11. chmod (Change Mode) - 权限赋能

12. chown (Change Owner) - 所属权变更

13. sudo (Superuser Do) - 临时提权

四、 系统监控与健康检查

14. df & du - 磁盘侦察

3. 创建 `.env`

4. 创建 `docker-compose.yml`

八、为什么不能只给 TeslaMate 配 `HTTP_PROXY`

一、引言：回归第一性原理

五、自动化运维：检查与验证

六、总结

一、基础导航与文件管理

1. `ls` (List) - 列出文件

2. `cd` (Change Directory) - 切换目录

3. `pwd` (Print Working Directory) - 确认坐标

4. `mkdir` (Make Directory) - 创建新空间

5. `rm` (Remove) - 慎用的“橡皮擦”

6. `cp` & `mv` - 复制与移动

二、文本处理与内容查看

7. `cat` (Concatenate) - 快速预览

8. `vim` / `vi` - 文本编辑神器

9. `grep` (Global Regular Expression Print) - 关键词检索

10. `tail` - 追踪末尾

三、权限与核心安全

11. `chmod` (Change Mode) - 权限赋能

12. `chown` (Change Owner) - 所属权变更

13. `sudo` (Superuser Do) - 临时提权

四、系统监控与健康检查

14. `df` & `du` - 磁盘侦察

15. `top` / `htop` - 实时任务管理器

16. `free` - 内存深度扫描

五、进程、网络与连接

17. `ps` (Process Status) - 进程状态

18. `kill` - 终止进程

19. `curl` - 网络请求工具

20. `ssh` (Secure Shell) - 远程之门

六、备份与压缩

21. `tar` (Tape Archive) - 打包与压缩

一、为什么选择 Hugo + GitHub？

二、准备工作（你需要准备什么）

三、实战步骤

四、掌握写作利器：Markdown (MD)

五、结语