欧丁 OwnDing

从买房踩坑到手搓一个日照网站：这玩意儿真能帮你避开“阴森森”的二手房

大家好啊！今天想跟你们唠点实在的——关于买房时那个让人抓狂的“日照问题”。多年前夏天，我差点在xx看中一套二手房，户型、价格都挺香，结果中介轻飘飘一句“采光嘛，还行吧”就糊弄过去了。等我挑冬天进去才发现，下午三点后客厅就黑得像电影院，晾个衣服都得靠烘干机。气得我直拍大腿：为啥没人告诉我真相？

后来一打听，市面上那些专业日照分析软件，动辄几千块年费，操作复杂得像开飞机——导入CAD图纸、调参数、等渲染……普通购房者谁受得了这个？尤其看二手房，房东和中介哪会给你掏钱买报告？我翻遍了小红书和知乎，一堆人吐槽：“想看看阳光能不能照进我家飘窗，咋比考驾照还难？”

一拍脑袋，我决定自己搞个工具。
我不是房产中介，就是个业余爱捣鼓的普通人。前几天，趁着周末和深夜，我吭哧吭哧开始写代码。说真的，过程挺狼狈：3D建模部分卡壳时，差点把键盘砸了；太阳轨迹算法调试到凌晨三点，咖啡杯堆成塔。不过呢，这次我偷偷用了点“外挂”——现在不是流行AI辅助编程嘛，像Copilot/ChatGPT这类工具帮我快速生成些基础代码片段，省了不少重复劳动。但核心逻辑全是自己抠的，比如怎么把经纬度、节气、楼高这些变量揉在一起算出真实阴影。重点不是AI多神，而是它让我这个半吊子能把精力花在刀刃上：让工具真正“傻瓜化”。

于是，这个小破站诞生了：SunSpot（名字土了点，但好记！）

打开它，你不会看到一堆吓人的参数表。首页就是一个干净的3D网格地图，像玩《我的世界》一样简单：

• 拖拖拽拽画房子：点“+”按钮加一栋楼，鼠标一拉就能调高度、改位置；不满意？直接删掉重来。二手房小区布局乱？自己还原真实场景就行。
• 太阳会“动”给你看：选个日期，比如冬至，界面上立刻画出太阳一整天的轨迹线，连阴影怎么爬过你家阳台都清清楚楚。再也不用脑补“下午四点会不会晒被子”了。
• 最狠的是这功能：点中任意一栋楼，再选具体楼层和户号（比如“5楼东户”），它直接甩给你一张表——24节气里，每天阳光照进你家窗台的精确时间。春分这天能晒2.5小时？大寒可能只有40分钟？数据全摊开，中介忽悠不了你。

上周我拿它试了试老家亲戚看中的一套老小区房子。亲戚原本觉得“楼层高肯定亮堂”，但SunSpot一算：对面新盖的写字楼在冬至那天，把阳光全挡了，下午根本见不着太阳。亲戚果断换房，后来发微信跟我吐槽：“早有这玩意儿，我何必白跑三趟售楼处！”

为什么坚持做成免费+极简？

因为我太懂普通人的痛了——买房是大事，不该被信息差割韭菜。那些收费软件把简单问题搞复杂，本质是吃定了你急着交定金。SunSpot没有登录墙、没有付费弹窗（靠我收入养着服务器呢）。技术上当然不完美：小bug还在修……但核心就一条：让你5分钟内，看清阳光会不会“住”进你家。

最后说点掏心窝子的

写代码时，我妈总笑我：“你一个买房的，咋还搞起气象站了？”但每次收到用户留言说“靠它避开了阴暗房”，就觉得那些熬夜的夜没白熬。技术不该是门槛，而是帮普通人把生活理得更明白的小梯子。

如果你最近在看房，尤其二手房，真心建议去试试 SunSpot。操作有疑问？评论区吼我，我手把手教。也欢迎吐槽——这站活着的唯一意义，就是替你挡住那些“看不见的阴影”。

需求

部署了私有化的 Harbor，需要 Harbor 同时支持 内网IP(HTTP)、外网IP(HTTP)、域名(HTTPS)进行访问。

配置

• 1、在 harbor.yaml 中配置 external_url

  1	external_url: http://62.132.105.159:5080

将 5080 端口映射到 外网，即可使用 http://62.132.105.159:5080 访问 Harbor。

• 2、使用域名访问

配置 nginx 代理，配置如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100

user  root;
worker_processes auto;

events {
    worker_connections 1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    sendfile        on;
    keepalive_timeout 65;

    gzip on;
    gzip_static on;

    proxy_buffer_size          128k;
    proxy_buffers              32 128k;
    proxy_busy_buffers_size    128k;

    fastcgi_buffers 8 128k;
    send_timeout 60;

    server_tokens off;

    # =========================
    # Harbor HTTPS Reverse Proxy
    # =========================
    server {
    listen 443 ssl http2;
    server_name xx.xxx.com;

    ssl_certificate      /home/cert/xx.xxx.pem;
    ssl_certificate_key  /home/cert/xx.xxx.key;

    client_max_body_size 0;

    # 建议给 registry 单独一段，避免某些客户端拉大层超时/缓冲问题
    location /v2/ {
        proxy_pass http://172.16.36.52:8894;

        # ✅关键：一定要用 $http_host，才能把 :5088 带进去
        proxy_set_header Host              $http_host;
        proxy_set_header X-Forwarded-Host  $http_host;

        # ✅关键：告诉 Harbor 外部访问端口是 5088（不是 443）
        proxy_set_header X-Forwarded-Port  5088;
        proxy_set_header X-Forwarded-Proto https;

        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;

        proxy_http_version 1.1;
        proxy_read_timeout 900;
        proxy_send_timeout 900;

        # 拉镜像层时建议关掉请求缓冲
        proxy_request_buffering off;
    }

    location /service/ {
        proxy_pass http://172.16.36.52:8894;

        proxy_set_header Host              $http_host;
        proxy_set_header X-Forwarded-Host  $http_host;
        proxy_set_header X-Forwarded-Port  5088;
        proxy_set_header X-Forwarded-Proto https;

        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;

        proxy_http_version 1.1;
        proxy_read_timeout 900;
        proxy_send_timeout 900;
    }

    location / {
        proxy_pass http://172.16.36.52:8894;

        proxy_set_header Host              $http_host;
        proxy_set_header X-Forwarded-Host  $http_host;
        proxy_set_header X-Forwarded-Port  5088;
        proxy_set_header X-Forwarded-Proto https;

        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;

        proxy_http_version 1.1;
        proxy_read_timeout 900;
        proxy_send_timeout 900;
    }
}

}

部署 Nginx 服务后，即可使用 域名访问、拉取 Harbor 数据。

1）背景：前端入口链路

我们的站点前端是典型的两层入口：

• HAProxy：公网入口（80/443），负责分流与转发
• Nginx：承载前端静态资源与后端反代

部署架构图

2）问题现象：同样是 SlowHTTP，HTTPS “十几秒断光”，HTTP 却能一直挂着

我们用 slowhttptest 测试 Slow Headers / Slowloris（慢慢发送请求头，让服务器长时间保持连接，最终耗尽连接资源）时：(HAProxy Technologies)

• HTTPS（443）：连接在 10 多秒左右大量断开，攻击很难长期占用资源
• HTTP（80）：连接能长期保持；攻击持续后才出现 429，但 429 会影响所有正常用户访问

原因 ： 一开始我们把防护都写在 Nginx（例如 header 超时等），结果出现非常反直觉的情况：HTTPS 有效，HTTP 无效。

3）根因分析：HTTP/HTTPS 的“第一层解析 HTTP 的位置”不同

这次的关键点不是 Nginx 配得对不对，而是：

Slowloris 卡住的是“第一层负责接收/解析 HTTP 请求头”的组件。

✅ HTTPS（443）为什么能防住

我的 443 链路是：

• HAProxy：mode tcp + SNI 分流（不解析 HTTP）
• 后端：send-proxy-v2 透传到 Nginx
• Nginx：负责 TLS 终止与 HTTP 解析（第一层真正“读请求头”的地方）

因此 Slowloris 的“慢请求头”最终会到 Nginx，Nginx 的相关超时策略会把它掐掉，所以你看到 HTTPS 连接会在十几秒内“断光”。

另外，Nginx 要接收 PROXY 协议，必须在 listen 上启用 proxy_protocol。(loadbalancer.org)

❌ HTTP（80）为什么最初防不住

我的 80 链路是：

• HAProxy：mode http（会解析 HTTP）

这意味着 HAProxy 才是第一层接收并解析 HTTP 请求头的地方。而 HAProxy 在收到完整请求之前不会把请求转发到后端（官方说明：只有收到完整请求才会发给后端，因此后端往往看不到 slowloris 流量）。(HAProxy Technologies)

所以你在 Nginx 上做的“读请求头超时”对 HTTP 链路会出现一个现实问题：

慢头连接根本没到 Nginx，就卡在 HAProxy 这一层了。

这就是“HTTPS 能防、HTTP 防不住”的根本原因：两条链路的防护点不在同一层。

4）最终解决方案：把 SlowHTTP 防护前移到 HAProxy 的 80（HTTP）入口

要在 HAProxy mode http 下解决 slowloris，核心就一条：

• timeout http-request：限制“收完整请求头”的最大时间（slowloris 依赖慢慢发头来续命，这条能直接掐断）(HAProxy Technologies)

在此基础上我们叠加 stick-table，用“按源 IP 的并发连接数 / 请求速率”做更精细的保护与兜底。(HAProxy Technologies)

5）最终版配置

下面给出最终版（精简但完整可用）的 HAProxy + Nginx 关键配置结构，你可以把业务路由部分按自己的域名/SNI/后端继续扩展。

A. HAProxy（最终版）

版本：haproxy:2.3（Docker）
说明：443 维持 TCP/SNI 分流，80 负责 HTTP 分流 + SlowHTTP 防护

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105

global
    log 127.0.0.1 local0
    daemon
    maxconn 2000

defaults
    log global
    option redispatch
    retries 3
    timeout connect 5s
    timeout client  50s
    timeout server  50s

# 管理页面（可选）
frontend admin_stats
    bind :8070
    mode http
    stats enable
    stats uri /admin
    stats refresh 30s
    stats auth admin:xxxxxxxx
    stats hide-version

#####################################################################
# HTTP :80 入口（关键：在这里防 slowloris / slowhttp）
#####################################################################
frontend header_front
    bind *:80
    mode http
    option httplog
    option forwardfor

    # --- 核心 1：专杀 Slow Headers / Slowloris ---
    # 限制接收完整请求头时间：慢头无法“续命”
    timeout http-request 10s

    # 可选：缩短 keep-alive 空等时间，减少连接长期占用
    timeout http-keep-alive 10s

    # 可选：收紧 client（视业务而定）
    timeout client 30s

    # --- 核心 2：stick-table（按IP并发/速率兜底）---
    stick-table type ip size 200k expire 30s store conn_cur,conn_rate(10s),http_req_rate(10s)

    # 连接一建立就跟踪：对“慢头阶段”的连接非常关键
    tcp-request connection track-sc0 src
    acl abuse_conn sc0_conn_cur gt 80
    tcp-request connection reject if abuse_conn

    # 请求层限速（按业务调整阈值）
    http-request track-sc0 src
    acl abuse_rps sc0_http_req_rate gt 100
    http-request deny deny_status 429 if abuse_rps

    # --- 你的业务分流规则（示例保留你的结构）---
    acl finereport_h5 hdr_dom(host) -i finereport.xxxxx.com.cn
    http-request redirect scheme https if finereport_h5

    acl iphone_browser  hdr_reg(User-Agent) -i iPhone
    acl ipad_browser    hdr_reg(User-Agent) -i iPad
    acl android_browser hdr_reg(User-Agent) -i Android
    use_backend app_backend if iphone_browser or ipad_browser or android_browser
    default_backend pc_backend

backend app_backend
    mode http
    option httpchk
    server mom 192.168.139.118:30001 check
    # 注意：不要再手动 set-header X-Forwarded-For，否则会和 option forwardfor 叠加导致 "ip, ip"
    http-request set-header X-Real-IP %[src]

backend pc_backend
    mode http
    server mom-app 192.168.139.118:30002
    http-request set-header X-Real-IP %[src]

#####################################################################
# HTTPS :443 入口（维持 TCP + SNI 分流，交给 Nginx 终止 TLS）
#####################################################################
frontend https_frontend
    bind *:443
    mode tcp

    tcp-request inspect-delay 5s
    tcp-request content accept if { req.ssl_hello_type 1 }

    acl app_host        req.ssl_sni -i app.xxxxx.com.cn
    acl finereport_host req.ssl_sni -i finereport.xxxx.com.cn

    use_backend app_https_backend       if app_host
    use_backend finereport_https_backend if finereport_host
    default_backend pc_https_backend

backend pc_https_backend
    mode tcp
    server mom-https 192.168.139.118:18443 send-proxy-v2

backend app_https_backend
    mode tcp
    server app-https 192.168.139.118:18443 send-proxy-v2

backend finereport_https_backend
    mode tcp
    server fr-https 192.168.139.118:18443 send-proxy-v2

关键点回顾：

• timeout http-request 是解决 HTTP slowloris 的“必杀开关” (HAProxy Technologies)
• stick-table 用于按 IP 做并发/速率兜底；http-request deny deny_status 429 是官方/手册常用写法 (HAProxy Technologies)

B. Nginx（最终版：只保留与链路相关的两句）

你不需要在这篇文章里展开 Nginx 的各类参数（因为这次问题本质在 80 的 HAProxy）。但为了说明链路，保留两句就够：

1
2
3
4
5

# HTTP 入口
listen 80;

# HTTPS 入口：接收 HAProxy send-proxy-v2
listen 443 ssl proxy_protocol;

proxy_protocol 的意义：让 Nginx 能从 HAProxy 透传的 PROXY 协议里获取真实源地址。(loadbalancer.org)

6）验证方式：怎么确认 HTTP 真的“像 HTTPS 一样”防住了

1. 再跑一次 slowhttptest（SLOW HEADERS 模式）

• 观察 80 端口：连接会在 timeout http-request 10s 附近开始大量断开，不会长期“挂住”
• 443 端口：保持原有效果（十几秒内大量断开）

2. HAProxy 日志/统计

• 你会看到更多连接在请求未完成阶段被拒绝/超时
• 若开了 stats（:8070），也能看到前端并发回落更快

7）总结：这次踩坑的真正经验

• 同样是 slowloris，HTTP/HTTPS 的防护点可能完全不同。
• 当 80 端口 HAProxy 是 mode http 时，慢头卡在 HAProxy，Nginx 的“读头超时”自然不生效。
• 解决它的正确方式是：在 HAProxy 80 入口加 timeout http-request + stick-table，把 slowhttp “掐死在入口层”。

几个月前，我做了一件“疯狂”的事——把 Headscale 这个本为单机设计的开源项目，硬生生改造成了支持 集群模式 的分布式系统。核心改动很简单：引入 集群 ID 机制。通过这个 ID，多个 Headscale 实例能协同工作，像乐高积木一样横向扩展。用户再也不用担心单点故障，节点规模也能轻松突破千级，甚至用户可无感一键切换节点。那会儿深夜改代码的茶杯还堆在桌角，但看到集群流量平稳跑起来时，值了。

而最近一个月，我又给自己挖了个更大的“坑”：多租户化改造。这次的目标很明确——让 Headscale 像 Tailscale 官方服务一样，支持多团队、多客户隔离运行。想象一下：市场部、研发部、外包团队各自拥有独立的网络空间，设备互不可见，策略分权管理，账单按租户拆分。技术上，我在认证层和数据层等关键模块加了租户隔离，配合之前的集群 ID 能力，终于把单体架构蜕变成真正的 “集群+多租户”双引擎。现在它不仅能扛住海量节点，还能让不同租户在同一个系统节点里“老死不相往来”。我们正从面向个人的 SaaS 服务，跨越到同时服务个人与企业的统一平台。更令人兴奋的是，结合近几个月将 Tailscale/Headscale 应用于工业场景的实践，我们的服务边界已从个人网络、企业 IT 延伸至智能制造等产业级场景。

坦白说，这过程像在飞行中给飞机换引擎。ACL 策略冲突、租户配额溢出、跨集群同步延迟……Bug 追着我跑。但当测试环境里两个租户的设备同时上线却互不干扰时，那种 “成了” 的心跳感，比在寒冬里用冰水冲脸还提神。

目前整个系统仍在紧锣密鼓开发/调试中。性能压测、审计日志、租户自助面板……这些拼图正一块块归位。我们离一个真正企业级的 Headscale 从未如此之近。 期待很快能和你分享完整方案——这次，开源世界或许真能长出媲美商业产品的羽翼。

A few months ago, I did something “crazy”: I transformed Headscale—a project originally designed for single-node deployments—into a distributed system supporting cluster mode. The core change was elegantly simple: introducing a Cluster ID mechanism. With this ID, multiple Headscale instances now collaborate like Lego bricks, scaling horizontally without limits. Users no longer fear single-point failures, node counts can effortlessly surpass thousands, and—best of all—users can seamlessly switch nodes with a single click. The teacups from those late-night coding sessions still clutter my desk, but watching cluster traffic glide smoothly made every sip worth it.

Over the past month, I’ve dived into an even deeper challenge: multi-tenancy transformation. The mission was clear—to make Headscale operate like Tailscale’s official service, enabling isolated networks for multiple teams and clients. Imagine this: Marketing, Engineering, and an external contractor team each own their private network realm. Devices stay invisible across boundaries, policies are delegated per team, and billing splits cleanly by tenant. Technically, I implemented tenant isolation across authentication layers, data layers, and other critical components—all fused with our existing Cluster ID capability. This finally evolved the monolithic architecture into a true “cluster + multi-tenancy” dual-engine system. Today, it doesn’t just handle massive node loads; it ensures tenants coexist on the same physical node yet remain “blissfully unaware of each other’s existence.” We’ve crossed from a personal-SaaS tool into a unified platform serving both individuals and enterprises. Beyond this, months of applying Tailscale/Headscale in industrial settings have expanded our vision: our solution now scales from personal networks and enterprise IT to smart manufacturing and beyond.

Let’s be honest—this felt like rebuilding an airplane mid-flight. ACL policy collisions, tenant quota overflows, cross-cluster sync delays… bugs hunted me down relentlessly. But the moment two tenants’ devices came online simultaneously in the test environment—without a single byte leaking between them—sent a jolt through me sharper than dousing my face with ice water in winter.

Right now, the entire system is in intense development and debugging phases. Performance stress tests, audit trails, tenant self-service dashboards… these puzzle pieces are snapping into place. We’ve never stood closer to an enterprise-grade Headscale. I can’t wait to share the full blueprint with you soon. This time, the open-source world might truly sprout wings strong enough to rival commercial giants.

尾巴甩一甩，双城生活像开了挂：我的跨城联网“耍赖”记

朋友们，你们有没有过这种抓狂时刻？上周六晚上，我正躺在B市老家的沙发上啃鸭脖，刷到A市家里电脑上存着的《猫和老鼠》4K修复版——馋得我直咽口水。要是搁五年前，我只能哀嚎着爬起来买高铁票，或者对着云盘转圈圈等下载。但现在？我掏出iPad，点开那个小狐狸头图标，十秒后，A市电脑的桌面就活蹦乱跳地出现在我眼前。延迟？不到20毫秒！汤姆追杰瑞的动画丝滑得像在客厅投影仪上播，连鸭脖的油都顾不上擦了。

说来话长，我家是“双城玩家”：工作日扎根A市（联通宽带老铁），周末窜回B市（移动宽带盟友）。以前远程办公？简直是渡劫——TeamViewer转圈圈，QQ远程卡成PPT，有次开视频会议，同事问我：“你背景音是拖拉机在耕地吗？” 我默默翻了个白眼，决定自救。

于是，我捣鼓起了自建Headscale（Tailscale的平替版，懂的都懂）。架设过程？咳，踩坑无数：路由器设置像解九连环，防火墙规则看得我眼冒金星。但一通“sudo”乱炖后，奇迹发生了——我家两台宽带，一个联通一个移动，原本像两个互掐的广场舞队（“你信号强？”“你网速快？”），居然被IPv6强行撮合成了好基友！两家都测过IPv6，通得像村口小卖部的WiFi，P2P直连？稳了！

最绝的是出门带iPad的体验。接上Tailscale的“魔法尾巴”（对，我就爱叫它尾巴，甩一甩就能回家），它自动嗅到A市电脑，像狗狗认主似的直连。用微软远程桌面操作？流畅到离谱！上周在B市咖啡馆改方案，同事偷瞄我屏幕：“你这不像远程啊，像本地开机？” 我得意一笑：“秘密是——我给网络装了火箭推进器。” 延迟18ms，打《原神》都能躲开钟离的岩脊，更别说办公时拖拽Excel像玩贪吃蛇了。

异地生活从此开挂：

• 上班摸鱼？ 不，是高效办公！B市早高峰地铁上，我用iPad给A市电脑渲染视频，到公司直接交片，老板以为我通宵了（其实我在被窝刷剧）。
• 休闲娱乐？ 周末回B市陪爸妈，饭后窝在阳台用iPad连A市电脑打《双人成行》，老爹凑过来看：“这游戏机挺新潮啊？” ——嘿嘿，您闺女在跨城云蹦迪呢。
• 应急救星？ 有次忘带U盘，B市亲戚急要照片。我远程连A市电脑导出，5分钟搞定。亲戚惊了：“你这网，比我家猫跑得还快！”

这方案让我觉得：所谓“家”，早就不限于四面墙了。它是一串IPv6地址，一条P2P隧道，外加一只甩来甩去的“狐狸尾巴”。

如果你也双城奔波，别再被运营商PUA了！折腾下Tailscale+IPv6，成本低到只花你一杯奶茶钱（电费另算，哈哈）。记住啊，网络世界里，距离不是问题——只要尾巴够长，心（和电脑）永远在手边。

最后灵魂一问：下次回B市，我要不要在A市电脑挂个自动煮咖啡的脚本？尾巴一甩，咖啡香飘三百公里…算了，先让我把鸭脖吃完。

（P.S. 联通移动的哥们别找我打广告，真香警告！）

—— 一个靠“尾巴”续命的数字游民，于B市阳台啃鸭脖时手打 🦊✨

Tailscale 在加入域的 Windows 电脑上运行异常：一次典型的“进程用户不一致”问题复盘

在日常使用 Tailscale / Headscale 进行企业级组网时，很多问题并不出现在协议、NAT、DERP 或控制面，而是发生在操作系统层面的细节。

本文记录一次真实遇到的问题：
同一套 Tailscale CLI 用法，在普通 Windows 电脑上一切正常，但在“已加入域（Domain Joined）”的 Windows 电脑上，却出现无法连接本地守护进程、401 Unauthorized 等异常。

问题本身并不复杂，但非常具有迷惑性，也很容易在企业环境中反复踩坑。

一、问题现象

在一台 已加入 AD 域的 Windows 电脑 上，使用 Tailscale CLI 方式运行（而非 Windows 服务模式）时，出现以下典型现象：

• 执行 tailscale up 时提示：

  • 无法连接到本地的 tailscaled 进程

• 执行 tailscale logout / status 时返回：

  • 401 Unauthorized
  • 提示当前 Tailscale 正在以 server / unattended mode 运行
  • 并明确指出：
    后台运行的用户 ≠ 当前 CLI 所属的用户

更让人困惑的是：

• 两个命令窗口都是“以管理员身份运行”
• 同样的操作，在未加入域的电脑上完全正常

这很容易让人误判为：

• 域策略限制
• 防病毒 / EDR 拦截
• 防火墙或端口问题
• Headscale 权限配置错误

但实际上，都不是。

二、核心原因：Windows 上的“进程用户” ≠ “管理员权限”

1️⃣ Windows 的一个关键事实（很多人会忽略）

在 Windows 上：

“以管理员身份运行” ≠ “使用同一个用户运行”

尤其在 域环境 中，常见的用户至少包括：

• 本地管理员（HOSTNAME\Admin）
• 域用户（DOMAIN\Username）
• SYSTEM（系统服务）

它们之间的区别不仅是权限，还包括：

• 不同的 用户 SID
• 不同的 用户 Profile
• 不同的 LocalAppData / Registry / Named Pipe / IPC 权限

2️⃣ Tailscale CLI 的工作方式（关键点）

在 Windows 上，Tailscale 的架构是：

• 一个 后台守护进程（tailscaled）
• 一个或多个 前台 CLI（tailscale）

两者通过 本地 IPC 通信。

重要约束：

Tailscale 的 CLI 只能与“同一用户上下文”下运行的 tailscaled 进行通信

一旦出现以下情况：

• tailscaled 是由 用户 A 启动的
• tailscale CLI 是由 用户 B 运行的（即便都是管理员）

那么结果就是：

• CLI 连接不上后台
• 或直接返回 401 Unauthorized

三、为什么“加入域”后更容易触发？

在未加入域的普通 Windows 电脑上，常见情况是：

• 所有人都用同一个本地管理员
• 用户切换、权限边界不明显
• 很难无意中启动“不同用户的后台进程”

而在 域环境 中，情况会复杂很多：

• 电脑加入域后，日常登录的是 域用户

• 某些运维操作、脚本、历史命令，可能是用 本地管理员 执行的

• 甚至可能：

  • 第一次启动 tailscaled 用的是本地 Admin
  • 之后日常操作用的是域账号

于是就出现了：

后台 tailscaled 被“某个用户”占用，而你已经无法用当前账号再控制它

这正是 401 报错中提示 “connection from XXX not allowed” 的真实含义。

四、为什么有时会同时看到两种错误？

不少人会遇到一种更“诡异”的组合现象：

• tailscale up → 提示连不上后台
• tailscale logout → 却返回 401 Unauthorized

这通常意味着：

• 后台进程 存在，但不在当前用户上下文
• IPC 有时能探测到，有时不能
• CLI 对不同命令路径的校验逻辑不同

本质仍然是：用户不一致导致的控制权问题。

五、正确、稳定的解决方案

✅ 方案一（推荐）：显式指定 state 目录，统一为机器级状态

在域环境中，最稳妥的方式是：

让 tailscaled 的状态不依赖任何“用户 Profile”，而是固定在机器级目录

例如使用：

1

.\tailscaled.exe --statedir=C:\ProgramData\Tailscale

这能解决多个关键问题：

• 不同用户登录不会产生多份 state
• 不会因为切换账号而“变成新设备”
• 减少用户 SID 差异带来的 IPC/权限问题
• 更符合企业服务器 / 运维主机的使用习惯

这是本文场景中最终生效、且最干净的解法。

✅ 方案二：严格保证“后台与 CLI 使用同一账号”

如果你坚持用 CLI 方式运行（而非 Windows 服务）：

• 必须确保：

  • 启动 tailscaled 的账号
  • 后续执行 tailscale CLI 的账号
    完全一致

仅仅“都是管理员”是不够的。

⚠️ 不推荐但可用：频繁 kill 后台重启

在调试阶段，有人会选择：

• 手动结束 tailscaled
• 重新用当前用户启动

这在测试时可行，但在企业环境、自动化、长期运行场景下并不可靠。

六、经验总结

这次问题的本质不是 Tailscale 或 Headscale 的 bug，而是：

Tailscale 在 Windows 上严格遵循“进程用户边界”，而域环境放大了这一差异

记住这几条，就能避免 90% 的类似问题：

1. Windows 域环境 ≠ 单用户桌面环境
2. 管理员权限 ≠ 相同用户身份
3. CLI ↔ 后台通信，强依赖用户上下文
4. 企业/域环境下，优先使用机器级 state 目录

七、写在最后

如果你正在用 Tailscale / Headscale 构建企业级、工业级、跨地域的组网方案，
那么这类 “操作系统层面的细节” 往往比协议本身更容易成为隐性故障源。

理解它、规避它，系统就会稳定得多。

如果你后续还遇到：

• 域环境 + unattended mode
• 多用户登录导致设备重复
• Windows Server 上的 Tailscale 行为差异

这些其实都属于同一类问题的不同表现。

问题

自建的headscale服务，在3台设备上登入同一个账号。这三台设备有2台是 windows电脑，记作A、B，1台是 Linux边缘网关记作C。三台都登入后，在ACL设置规则让3台设备互通，但是发现一个问题，即A、B可以相互 ping 通，A、B任何一台都无法 ping 通 C。只有当ssh到C设备，在C设备发起 ping A或B 后（可以 ping 通A、B），同时 A、B就能 ping 通 C了。
在 C 上使用 tailscale netcheck 命令发现如下信息：

1
2
3
4
5
6

* UDP: true
* IPv4: yes, 115.199.109.106:49676
* IPv6: no, unavailable in OS
* MappingVariesByDestIP: true
* PortMapping: UPnP
* Nearest DERP: hw-shanghai

先说结论：
这个现象本质上是 C 在一个“比较难搞的 NAT + UPnP 环境”里，在它主动往外发一次包之前，Tailscale 没有为它准备好一个“可从公网直接打进来的端口映射”，所以 A/B 先打它时没路可走；等 C 主动 ping 一下 A 之后，通过 UPnP 成功在路由器上开了一个外部 UDP 端口，从那一刻起其它节点就能主动连到 C 了，所以你看到“C 先发一次之后就都通了”的效果。

1. 先解读一下 netcheck 的两组输出

C（嵌入式网关）上的 netcheck

1
2
3
4
5
6

* UDP: true
* IPv4: yes, 115.199.109.106:49676
* IPv6: no, unavailable in OS
* MappingVariesByDestIP: true
* PortMapping: UPnP
* Nearest DERP: hw-shanghai

关键点：

• MappingVariesByDestIP: true
  说明 C 后面的 NAT 是 hard NAT / symmetric NAT，也就是“对不同目的地址会用不同的 (IP, port) 映射”，属于比较难穿的那种 NAT。(tailscale.com)
• PortMapping: UPnP
  说明 tailscaled 在 C 上 成功通过 UPnP 在你家路由器上申请了一个外部端口映射（本质上就是给 41641/UDP 开了个洞），借助这个端口映射，哪怕后面依然是 hard NAT，也有机会做到“外面主动打进来”。(tailscale.com)

官方文档的解释是：

• MappingVariesByDestIP = true → “这个设备在不同 DERP 上看到的外网 (IP,port) 不一样，基本就是 hard NAT，只靠 UDP 打洞很难搞，通常只能走 DERP 中继”。(tailscale.com)
• PortMapping = UPnP → 设备通过 UPnP / NAT-PMP / PCP 之类协议可以在路由器上开端口，这会把它从“完全 hard NAT”拉回到“相对容易打洞的 NAT”，提高直连成功率。(tailscale.com)

A（Windows）上的 netcheck

1
2
3
4
5

* UDP: true
* IPv4: yes, 123.152.221.80:55074
* IPv6: no, but OS has support
* MappingVariesByDestIP: false
* PortMapping:

• MappingVariesByDestIP: false → A 所在网络是 easy NAT 或无 NAT，端口映射对不同目的地址是稳定的，属于很好穿的类型。(tailscale.com)
• PortMapping: 为空 → 说明 A 侧路由器没有用 UPnP/PCP/NAT-PMP 做额外端口映射，但因为 NAT 本身是“easy”的，所以也不需要。(tailscale.com)

所以整体形势是：

• A / B：在一个 easy NAT / 普通家用 NAT 后面，比较好打洞。
• C：在一个 hard NAT + 支持 UPnP 的路由器 后面，理论上可以通过 UPnP 把它变成“可被外界直接访问”的节点，但前提是 UPnP 端口映射已经真正建立。

2. 为啥“一开始 A/B ping 不通 C，C 先 ping 一下 A 之后就都好了”？

结合 Tailscale 的连接流程，可以大致这样理解：(tailscale.com)

1. 刚开始时的状态

   • C 刚上线，tailscaled 还没完全跑完所有探测 / 打洞 / UPnP 端口映射逻辑，或者 UPnP 端口映射还没建立好。

   • 从 headscale 的角度，它知道 C 的存在，但 对 C 的“可达外网端点（external endpoint）”信息还不稳定。

   • 这时候 A/B 看到 C 在线了，就开始往 C 的 100.x IP 发 ICMP ping：

     • OS 把 ICMP 包扔进 tailscale0；

     • tailscaled 尝试用当前掌握的 C 的 endpoint 建立 WireGuard 通道；

     • 由于 C 这边 NAT 比较凶（MappingVariesByDestIP:true），再加上此时可能还没搞定 UPnP 端口映射/打洞，导致：

       • 直连 UDP 打洞暂时失败；
       • DERP 也还在尝试协商 / 或者路径不稳定；

     • 结果就是：从 A/B 看起来就是 “ping 不通 C”。

2. C 主动 ping A 时发生了什么

   当你在 C 上执行 ping 100.x.x.x(A) 或 tailscale ping A 的那一刻，会触发一堆事情：

   • C → headscale/DERP 方向会有新的 DISCO / STUN / netmap 相关流量：

     • tailscaled 再次探测外网出口，更新自己的 (公网IP, 端口) 组合；
     • 再次执行或刷新 UPnP 端口映射，在路由器上为 C 打开一个稳定端口（你 log 里那几行 UPnP reply 就是这个过程）。

   • headscale 收到 C 更新后的网络信息后，会把 最新的 endpoint/portmapping 信息 发给 A/B。

   • A/B 端的 tailscaled 收到更新后再试着连 C，此时：

     • 要么能通过 C 的 UPnP 映射端口 直接打进来；
     • 要么至少能可靠地通过 DERP 建立中继通路。

   • 于是，你看到：

     • C ping A 正常；
     • 紧接着再 A ping C 也突然开始正常了。

3. 为什么后面重启 C / 重启 A 之后依然能互通？

   有两种常见情况都能解释你看到的“之后一直通”：

   • UPnP 映射在路由器里是持久的或长时间不失效
     很多家用路由的 UPnP 映射要么：

     • 写进配置（重启客户端不丢），
     • 要么有很长的超时时间（比如几个小时甚至更长）；
       只要路由器本身没重启、没有清表，这个 外部端口 → C:41641 的映射就一直在。
       所以哪怕 C 重启、A 重新登录，新的 tailscaled 继续用这个端口，A/B 都能直接打进来。

   • 即便 UPnP 映射后来过期，硬 NAT 的行为对「这个 DERP/这个 peer」变得稳定了
     一旦 C 对某些 DERP / 目标发了足够多的流量，NAT 的分配策略趋于稳定，配合 Tailscale 的路径探测与缓存，后续的打洞就更容易成功。
     再加上 headscale/clients 会把可用路径缓存一段时间，所以“通了以后一直通”是常见现象。

3. 那个 PortMapping: UPnP 到底意味着什么？

结合文档简单翻译下：(tailscale.com)

• 这行不是说“现在一定在用 UPnP 通信”，而是说：

  “当前设备已经确认可以通过 UPnP/PCP/NAT-PMP 之类协议在网关上申请端口映射，并且已经申请到了。”

• 这对 C 这种 MappingVariesByDestIP: true 的 hard NAT 场景非常关键：

  • 单纯靠 UDP 打洞很难；
  • 但一旦能在路由器上开一个 固定外部端口，其它设备就可以一直往这个端口打，而不用和 NAT 的随机策略博弈。

所以你看到的流程，其实很像：

1. C 启动时还没来得及把 UPnP 端口映射搞定，A/B 先打 → 不通。
2. 你从 C ping 一下 A，顺便触发了端口映射创建/刷新。
3. 从那一刻起，C 变成“背后有静态端口映射的节点”，其它节点就可以随时主动连它了。

4. 这是不是 Bug？需要怎么调优/验证？

从 Tailscale 官方的角度，这更像是 复杂 NAT 环境下的时序问题 + UPnP 行为，不算标准的“功能 Bug”，但确实有优化空间。

你可以做几组实验来印证上面的推断：

4.1 看看 A ↔ C 之间实际是直连还是走 DERP

在 A 上：

1
2
3

tailscale status
tailscale status 100.xxx.xxx.xxx   # C 的 tailscale IP
tailscale ping C-Hostname          # 或 tailscale ping 100.x.x.x

观察输出里有没有：

• direct x.x.x.x:41641 → 直连
• relay "hw-sh" / via DERP(hw-shanghai) → 走中继

文档里有样例：前几包经 DERP，再切换到 direct 是正常的握手过程。(tailscale.com)

4.2 复现一次“刚上线不通”的过程，再对比 log

下次你可以：

1. 重启 C（或者断电再上电，让 tailscaled 完全冷启动）。

2. 先不要从 C 发任何东西，只在 A 上：

   1	tailscale ping --tsmp --verbose C

   TSMP ping 会绕过 OS IP 栈，直接看 Tailscale 通道本身，--verbose 会打印路径信息。(tailscale.com)

3. 如果这时候仍然 ping 不通，再在 C 上执行一次：

   1	tailscale ping --tsmp --verbose A

4. 对比前后两次 tailscale ping 输出，以及 /var/log/tailscaled.log 中的 NAT 路径变化。

你应该能看到类似：

• 先只有 via DERP(...)，甚至前几次完全没 pong；
• C ping A 之后，出现 via 123.123.123.123:41641 的 direct 路径。

4.3 试试禁用 UPnP 看行为是否更一致

在你这个 TP-Link（TL-XDR6030 易展版）路由器里，把 UPnP 功能关掉，让 C 完全处在 hard NAT + 无端口映射的环境，然后看看现象变成什么样：

• 理论上，这时 C 往往只能通过 DERP 收发数据，PortMapping: 会为空，MappingVariesByDestIP: true 依旧。(tailscale.com)
• 正常情况下，即便只能走 DERP，也不应该出现“完全 ping 不通，直到对方先发一次”的情况——如果还出现，就更像是 headscale 侧或你自己的 tailscale fork 里有逻辑 bug，可以重点排查。

5. 小结一句话版

之所以必须先在 C 上向 A/B 发一次包，才会出现 A/B 能 ping 通 C，是因为 C 所在的网络是 hard NAT，Tailscale 需要在 C 主动发包时，借助 UPnP 在路由器上开一个稳定的外部 UDP 端口；在这个端口映射建立之前，A/B 主动打 C 找不到可用路径，一旦映射建立并被 headscale/客户端缓存之后，后续就可以随时主动连 C 了。

很多人在 k8s 集群里习惯这样做：
前端用一个 Nginx Deployment，当成“自建 Ingress / 前端网关”，然后在 nginx.conf 里直接用 Service 名称 去反向代理后端服务。

一开始一切正常，但当你 更新后端服务 之后，诡异的问题来了：

• Nginx 容器里 ping 这个 Service 完全没问题
• 但通过 Nginx 访问接口，就是 502 / 连接不上
• 重启一下 Nginx Pod，又好了……

这其实就是：Nginx 的 DNS 缓存在 k8s 场景下坑了你。

下面就用一个真实案例，完整说明：

• 问题现象
• 背后原因（Nginx + k8s Service + DNS 的联动）
• 两套可落地的解决方案（原生 Nginx + Tengine 动态解析），附完整配置

一、问题：后端升级后，Nginx 无法再访问 Service

场景简化一下：

• 前端：一个 Nginx Pod，做反向代理
• 后端：若干微服务，通过 k8s Service 暴露，如 demo-dlp-service.huanfa
• Nginx 里直接写：

1

proxy_pass http://demo-dlp-service.huanfa:80;

现象：

• 初次部署时，一切访问正常

• 当你 更新后端 Deployment / 重建 Service / 变更 Endpoints 后

  • Nginx 容器里 ping demo-dlp-service.huanfa 仍然能 ping 通
  • 但浏览器访问前端页面时，接口变成 502/超时
  • 重启下 Nginx Pod 又恢复正常（直到下一次后端更新）

这类问题常让人误以为是：

• k8s 网络有问题？
• Service 没更新？
• Pod 探针 / readiness 有坑？

实际上，非也——核心问题在于：Nginx 的 DNS 解析结果被缓存住了。

二、原因：Nginx 只在“第一次”解析域名，之后就不再更新

在传统物理机 / 虚拟机环境中，后端服务器 IP 很少变，所以 Nginx 默认的 DNS 行为一直没啥问题：

• 配置里写了 proxy_pass http://some-domain:80;
• Nginx 在启动或第一次处理请求时做一次 DNS 解析
• 把解析出来的 IP 缓存在内存里，之后就一直用这个 IP

但是在 k8s 环境里，Service 对应的后端 Pod IP 是会变的：

• 滚动升级 / 重启 Pod
• HPA 扩容缩容
• 节点故障迁移

都会导致 Service 背后的 Endpoints 变化。

而如果你 只是简单地在 proxy_pass 里写了 Service 名称，又没有额外配置 DNS 相关指令，那么：

Nginx 仍然只会在“第一次”解析 Service 的域名，后面就一直用旧 IP。
这就是为什么你在 Nginx 容器里 ping 没问题（系统 DNS 是新的），
但 Nginx 自己还是连旧的 Pod（甚至已经不存在的 IP）——自然就访问失败了。

三、解决方案一：在原生 Nginx 中启用动态 DNS 解析（resolver + set）

在 nginx 1.18.0 版本中测试通过。

核心思路：

1. 告诉 Nginx：DNS 服务器是谁（比如 k8s 里的 kube-dns）
2. 将 Service 名称赋值给一个变量
3. 在 proxy_pass 中使用这个变量
4. 这样 Nginx 就会在访问时按 valid=… 设定，周期性重新解析域名

完整配置如下（保持原样，不做任何修改）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

user  root;
worker_processes auto;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    access_log /var/log/nginx/nginx-access.log;
    error_log /var/log/nginx/nginx-error.log;
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    
    sendfile        on;
    keepalive_timeout  65;
    gzip on;
    gzip_static on;
    proxy_buffer_size 128k;
    proxy_buffers 32 128k;
    proxy_busy_buffers_size 128k;
    fastcgi_buffers 8 128k;
    send_timeout 60;
    server {
        listen       80;
        server_name  demo-dlp-service.huanfa;
        resolver kube-dns.kube-system.svc.cluster.local valid=5s;
        # resolver_timeout 3s;
        set $endpoint_service demo-dlp-service.huanfa.svc.cluster.local;
        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;
        location / {
            proxy_pass http://$endpoint_service:80;
        }
    }
}

关键配置说明

• resolver kube-dns.kube-system.svc.cluster.local valid=5s;

  • 指定 Nginx 使用 k8s 的 DNS 服务（kube-dns）进行解析
  • valid=5s 表示解析结果最多缓存 5 秒，过期后会重新查

• set $endpoint_service demo-dlp-service.huanfa.svc.cluster.local;

  • 把 Service 的完整域名（一定要写全 FQDN）赋值给变量 $endpoint_service

• proxy_pass http://$endpoint_service:80;

  • 使用变量做 proxy_pass，配合上面的 resolver，就能让 Nginx 定期重新解析域名

这种方案适用场景

• 已经在用 原生 Nginx（官方镜像等），不方便切到 Tengine
• 服务数量不算特别多，Nginx 做简单前端网关
• 希望配置简单、变更小，只是补上 DNS 动态解析能力

四、解决方案二：使用 Tengine 的 dynamic_resolve 功能

如果你愿意使用淘宝开源的 Tengine 3.1，可以直接用其内置的 dynamic_resolve 动态解析能力。

重点注意：Service 地址一定要写完整 FQDN，例如：
imes-system-service.demowms.svc.cluster.local。

下面是完整配置（保持原样，不做任何修改）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160

# Generated by nginxconfig.io
# See nginxconfig.txt for the configuration share link
user                 nginx;
pid                  /usr/share/nginx/temp/nginx.pid;
worker_processes     auto;
worker_rlimit_nofile 65535;
# Load modules
include              /usr/share/nginx/conf/modules-enabled/*.conf;
events {
    multi_accept       on;
    worker_connections 65535;
}
http {
    charset                utf-8;
    sendfile               on;
    tcp_nopush             on;
    tcp_nodelay            on;
    server_tokens          off;
    log_not_found          off;
    types_hash_max_size    2048;
    types_hash_bucket_size 64;
    client_max_body_size   16M;
    # MIME
    include                mime.types;
    default_type           application/octet-stream;
    # Logging
    access_log             /usr/share/nginx/logs/access.log;
    error_log              /usr/share/nginx/logs/error.log warn;
    gzip on;
    gzip_disable "msie6";
    gzip_comp_level 6;
    gzip_min_length 1100;
    gzip_buffers 16 8k;
    gzip_proxied any;
    gzip_types
        text/plain
        text/css
        text/js
        text/xml
        text/javascript
        application/javascript
        application/x-javascript
        application/json
        application/xml
        application/rss+xml
        image/svg+xml/javascript;
    proxy_buffer_size 128k;
    proxy_buffers 32 128k;
    proxy_busy_buffers_size 128k;
    fastcgi_buffers 8 128k;
    send_timeout 60;
    resolver_timeout 5s;
    resolver kube-dns.kube-system.svc.cluster.local ipv6=off;
    upstream sys {
        dynamic_resolve  fallback=stale fail_timeout=15s;
        server imes-system-service.demowms.svc.cluster.local:8150;
    }
    upstream ppc {
        dynamic_resolve fallback=stale fail_timeout=15s;
        server imes-ppc-service.demowms.svc.cluster.local:1100;
    }
    upstream dev {
        dynamic_resolve fallback=stale fail_timeout=15s;
        server imes-dev-service.demowms.svc.cluster.local:2100;
    }
    upstream wms {
        dynamic_resolve fallback=stale fail_timeout=15s;
        server imes-wms-service.demowms.svc.cluster.local:8155;
    }
    upstream fts {
        dynamic_resolve fallback=stale fail_timeout=15s;
        server imes-fts-service.demowms.svc.cluster.local:8190;
    }
    upstream flowable {
        dynamic_resolve fallback=stale fail_timeout=15s;
        server imes-flowable-service.demowms.svc.cluster.local:1587;
    }
    upstream po {
        dynamic_resolve fallback=stale fail_timeout=15s;
        server imes-po-service.demowms.svc.cluster.local:1200;
    }
  server {
        listen       443 ssl;
        server_name  webServer;
        ssl_certificate      /home/cert/server.crt;
        ssl_certificate_key  /home/cert/server.key;
        ssl_session_cache    shared:SSL:1m;
        ssl_session_timeout  5m;
        ssl_ciphers  HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers  on;
        autoindex_localtime on;
        client_max_body_size 1200M;
        root /usr/share/nginx/html;
        index index.html;
        
        location ^~/api/ppc/ {
            # resolver 10.122.37.170 valid=5s;
            proxy_read_timeout 300s;
            proxy_pass  http://ppc/api/ppc/;
        }
        location ^~/api/dev/ {
            # resolver 10.122.37.170 valid=5s;
            proxy_read_timeout 300s;
            proxy_pass  http://dev/api/dev/;
        }
        location ^~/api/wms/ {
            # resolver 10.122.37.170 valid=5s;
            proxy_read_timeout 300s;
            proxy_pass  http://wms/api/wms/;
        }
        location ^~/api/sys/ {
            # resolver 10.122.37.170 valid=5s;
            proxy_read_timeout 300s;
            proxy_pass  http://sys/api/sys/;
        }
        location ^~/api/fts/ {
            # resolver 10.122.37.170 valid=5s;
            proxy_read_timeout 300s;
            proxy_pass  http://fts/api/fts/;
        }
        location ^~/static/ {
            proxy_pass  http://fts/static/;
        }
        location ^~/api/fluent/ {
            proxy_read_timeout 1s;
            proxy_pass  http://69.139.185.178:28081/api/fluent/;
        }
        location ^~/api/flowable/ {
            # resolver 10.122.37.170 valid=5s;
            proxy_read_timeout 300s;
            proxy_pass  http://flowable/api/flowable/;
        }
        location ^~/api/im/ {
            proxy_read_timeout 300s;
            proxy_pass  http://192.168.0.117:30010/api/im/;
        }
        location ^~/api/po/ {
            # resolver 10.122.37.170 valid=5s;
            proxy_read_timeout 300s;
            proxy_pass  http://po/api/po/;
        }
        location / {
            root /usr/share/nginx/html/;
            add_header Cache-Control no-store;
            rewrite ^.+(?<!js|css|png|ico|jpg|jpeg|woff|ttf|map|otf)$ /index.html break;
            index index.html;
        }
        location ~* \.(?:js|css|png|jpe?g|gif|ico)$ {
            # add_header  Content-Encoding  gzip;
            gzip_static on;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/share/nginx/html/;
        }
    }
}

关键点解析

• resolver kube-dns.kube-system.svc.cluster.local ipv6=off;

  • 同样是指定使用 k8s 的 DNS

• upstream sys { dynamic_resolve fallback=stale fail_timeout=15s; … }
  以及其它一系列 upstream：

  • dynamic_resolve：开启动态解析
  • fallback=stale：当解析失败时，继续使用旧的 IP，避免瞬时解析失败导致大面积 502
  • fail_timeout=15s：失败后多长时间内视为不可用

• server imes-xxx-service.demowms.svc.cluster.local:端口;

  • 一定要写完整的 FQDN（*.svc.cluster.local），否则可能无法正确解析

这种方案适用场景

• 你愿意使用 Tengine 作为前端 Web 服务器
• 有大量后端服务 / 复杂路由，需要更强大的 upstream 能力
• 希望在解析出问题时有更优雅的降级（例如 fallback=stale 继续使用旧 IP）

五、实践中的几个小建议

无论你选用哪种方案，建议注意以下几点：

1. 永远使用 Service 的全限定域名（FQDN）
   比如：my-service.my-namespace.svc.cluster.local
   避免依赖 search domain，减少“在某些环境下突然解析失败”的坑。

2. 适当调小 DNS 缓存时间

   • 原生 Nginx：valid=5s 是比较折中的设置
   • Tengine：搭配 dynamic_resolve 使用
     时间太短会增加 DNS 压力，太长又起不到动态更新的效果，一般 5–30 秒比较合适。

3. 区分“系统 DNS 能 ping 通”和“Nginx 内部解析是否更新”

   • ping service 成功，只说明 容器的 /etc/resolv.conf + CoreDNS 正常
   • Nginx 使用的是 自己的 DNS 缓存机制，必须通过 resolver / dynamic_resolve 主动接入。

4. 升级 / 重启策略

   • 即便有了动态解析，生产环境里还是建议对 Nginx 做滚动升级 / 定期 reload
   • 避免因为历史配置 / 旧连接导致的边角问题

六、总结

在 k8s 中使用 Nginx 作为前端服务器时，DNS 缓存问题是一个非常容易被忽略的坑：

• 表面上看是“后端升级后，Nginx 偶尔 502 / 访问失败”
• 实际上是：Nginx 只在第一次解析域名，后面 Service 或 Pod IP 变了，它却仍然握着旧 IP 不放

本文基于实际案例，给出了两种实测可行的解决方案：

1. 原生 Nginx：
   使用 resolver + set + 变量 proxy_pass，在 nginx 1.18.0 上验证通过

2. Tengine：
   使用 dynamic_resolve，支持更丰富的动态解析和降级策略

如果你也在 k8s 里用 Nginx 直连 Service，建议尽快检查自己的 nginx.conf，
看看是不是还停留在“写死一个 Service 名称”的阶段——
早点补上 DNS 动态解析配置，可以少踩很多坑。

🌐 无感迁移的艺术：Headscale SaaS 环境下的用户无缝切换实战

摘要：当你的 Headscale SaaS 服务需要扩容、维护或负载均衡时，如何让百万用户”毫无知觉”地完成服务迁移？本文揭秘从 Traefik 到系统层的无感切换技术，让你的 Headscale 服务如丝绸般顺滑！

📜 前言：从 SaaS 架构到无感体验

在上一篇博文中，我们详细介绍了如何构建 Headscale SaaS 架构，实现多租户隔离与资源分配。但随着业务增长，新的挑战浮现：

“当需要迁移用户到不同 Headscale 节点时，如何避免用户断连重认证？”

在实现 Headscale 多节点部署时遇到了以下几个痛点：

• 客户端长连接顽固不化，即使后端变了也”死抱着旧节点不放”
• 强制重启服务导致该节点所有用户客户端断联一小会儿，体验极差
• 尝试在 Traefik/Envoy/Haproxy 层中断旧长连接却屡屡失败

今天，我们将揭晓无感迁移的完整方案，让Headscale集群用户在服务迁移过程中”毫无察觉”，就像魔法师的障眼法一样神奇！

🏗️ 一、我们的 SaaS 架构：域名驱动的 Headscale 集群

首先回顾一下我们的 Headscale SaaS 架构（已优化升级）：

（架构图：清晰展示客户端 → Traefik → Nginx → Headscale 的数据流）

🔑 核心设计理念

1. 域名即身份：为每个用户分配唯一子域名（如 hsa.demo.com）
2. 统一入口：所有子域名解析到同一台 Traefik 服务器
3. 动态路由：Traefik 根据域名热更新，将流量导向对应的 Headscale 节点
4. 数据隔离：PostgreSQL 中通过 cluster_id 隔离不同节点的数据

💡 关键价值：用户永远记住自己的专属域名（如 hsa.demo.com），而无需关心后端服务在哪台机器上运行！

🧪 二、迁移挑战：顽固的 TCP 长连接

Tailscale 客户端一旦连接 Headscale，会建立持久 TCP 连接（通常持续数小时甚至数天）。这带来了迁移难题：

🚫 为什么 Traefik 无法中断连接？

我们尝试了多种方案，全部失败：

核心问题：TCP 是传输层协议，不携带应用层信息（如域名、用户ID）。即使 Traefik 知道 hsa.demo.com 应该指向新节点，也无法识别哪些连接属于这个域名！

🌟 三、突破：系统层精准连接中断术

经过深入研究，我们找到了高效可行方案：在 Headscale 服务器上精准关闭目标客户端的 TCP 连接！（以下中断连接方案只做初步说明，有多种方案，只介绍一种方便演示的方案）

✅ 为什么这招有效？

1. 精准定位：通过客户端 IP 识别连接（而非域名）
2. 系统级操作：直接操作内核连接表
3. 无副作用：不影响其他用户连接
4. 触发重连：客户端自动使用 node key 重建连接

🔧 操作步骤（以迁移用户 hsa 为例）

步骤 1：数据迁移（确保无缝衔接）

1
2
3
4
5
6
7
8
9
10

# 1. 从节点3导出 hsa 用户数据
pg_dump -h node3-db -U headscale -t nodes -t ip_addresses \
  --where="user_id = (SELECT id FROM users WHERE name = 'hsa')" \
  > hsa_data.sql

# 2. 修改 cluster_id (3 → 4)
sed -i 's/cluster_id: 3/cluster_id: 4/g' hsa_data.sql

# 3. 导入到节点4数据库
psql -h node4-db -U headscale -d headscale < hsa_data.sql

步骤 2：更新 Traefik 配置（热更新！）

1
2
3
4
5
6
7

# traefik-dynamic.yaml
http:
  routers:
    hsa-router:
      rule: "Host(`hsa.demo.com`)"
      service: "headscale-cluster4"
      entryPoints: ["https"]

1
2

# 无需重启，立即生效！
curl -X POST http://traefik/api/providers/file?dynamic=true

步骤 3：精准中断连接（关键一步！）

1
2

# 在 Headscale 节点3上执行
ss -K "dport = 7890 and src 203.0.113.5"

✨ 魔法时刻：客户端在 5 秒内自动重连，使用原有 node key 连接到新节点，无需重新认证！

🎯 四、无感迁移原理图解

让我们深入理解这个”魔法”是如何工作的：

（原理图：详细展示从连接中断到无缝重连的全过程）

🔑 三大关键保障

1. Node Key 持久化
   客户端本地存储 /var/lib/tailscale/tailscaled.state，重连时自动使用

2. 数据库一致性
   新旧 Headscale 共享 PostgreSQL，识别相同 node key

3. Tailscale 协议设计
   连接中断后自动重试，不是新注册，无需重新认证

🛠️ 五、实战：迁移

📊 迁移效果实测数据

🌈 六、为什么这比其他方案更优雅？

核心优势：

• 零认证中断：用户完全不需要重新登录
• 精准控制：只影响目标用户，不影响其他租户
• 无缝体验：网络短暂波动，应用层可能无感知

🚀 七、结语：SaaS 服务的终极体验

通过这套方案，我们成功构建了真正用户无感的 Headscale SaaS 服务：

1. 域名即身份：用户永远记住自己的专属域名
2. 动态负载：根据需求灵活迁移用户
3. 无缝切换：系统层精准中断连接，触发无感重连
4. 弹性扩展：轻松应对流量高峰和节点维护

“最好的基础设施，是用户完全感觉不到它的存在。”
—— 当你的网络服务像空气一样自然，用户才会真正专注于他们的业务。