1. 项目概述：为什么在 Ubuntu 20.04 上坚持用 Traefik v1 做 Docker 反向代理？
Traefik v1 是一个被大量生产环境验证过的、轻量级且自动化的反向代理与负载均衡器，它专为容器化场景而生。虽然官方早已停止对 v1 的维护（v2 系列自 2019 年起成为主力），但直到今天，仍有大量运行在 Ubuntu 20.04 上的遗留系统、嵌入式边缘网关、CI/CD 测试集群、教育实验环境，甚至部分金融与制造行业的内部运维平台，依然稳定依赖 Traefik v1。这不是“过时”，而是“稳态选择”——就像你不会因为有了 iPhone 15 就立刻扔掉还在跑 iOS 12 的 iPad Air 2，只要它能精准完成任务、不引入新风险、不增加维护成本，它就是合理的技术资产。
我过去三年里维护的 7 个客户现场中，有 4 个明确要求保留 Traefik v1：一个是因为其 Kubernetes Ingress Controller（v1.7）与旧版 Rancher 2.2 集成深度绑定；另一个是某高校实验室的 Docker Compose 教学平台，所有实验手册、学生脚本、考核评分系统都基于traefik.frontend.rule这套 v1 特有的标签语法；还有一个是工业 PLC 数据采集网关，运行在物理机 Ubuntu 20.04 上，内核锁定为 5.4.0-122，而 Traefik v2.9+ 要求 Go 1.19+，编译后在该内核下偶发 goroutine 调度异常，回退到 v1.7.32 后连续 412 天零重启。这些不是理论推演，是真实压在运维肩上的 SLA 和交付红线。
所以，这篇内容不是教你怎么“追新”，而是帮你把一件已经上线、正在跑、不能随便动、但又需要你接手调优或排障的事，真正搞明白、管得住、改得稳。它面向三类人：第一类是刚接手老系统的 junior DevOps，看到docker-compose.yml里一堆traefik.开头的 labels 一脸懵；第二类是教学场景下的讲师或助教，需要给学生讲清楚“为什么这个 rule 写法和网上搜到的 v2 教程不一样”；第三类是嵌入式/IoT 场景开发者，资源受限（内存 <512MB）、系统冻结（Ubuntu 20.04 LTS + kernel 5.4）、升级路径闭塞，必须吃透 v1 的每一个行为边界。我们不谈“未来趋势”，只聚焦“此刻如何让这台 Ubuntu 20.04 机器上的 Traefik v1 继续可靠地转发每一个 HTTP 请求”。
核心关键词——Traefik、v1、Docker、Ubuntu、20.04——不是随意堆砌的标签，而是构成技术约束的五根支柱：Traefik 指定了软件行为范式（自动发现、标签驱动）；v1 锁定了配置模型（frontends/backends分离、file/docker提供者并存）；Docker 定义了服务注册方式（通过 Unix socket 监听容器事件）；Ubuntu 是操作系统基座（决定了 systemd 单元写法、apt 源策略、SELinux/AppArmor 默认状态）；20.04 则是具体的 ABI 兼容层（glibc 2.31、systemd 245、默认启用 ufw 防火墙）。漏掉其中任意一环，配置就可能在某个凌晨三点失效——比如你照搬 Ubuntu 18.04 的traefik.service文件到 20.04，会因RuntimeDirectoryMode=0755缺失导致启动失败；又比如你用 v2 的--providers.docker.exposedbydefault=false参数去启动 v1，Traefik 会直接报错退出，连日志都不写一行。
这篇文章要解决的，正是这种“看似简单、实则处处是坑”的落地问题。它不承诺“一键部署”，但保证你读完后，能独立判断：当前配置是否符合 v1 的语义规范？Docker 容器的 labels 是否被正确识别？Traefik 日志里那行stream disconnected before completion: error sending request for url (http://127.0.0.1:57321/v1/responses)真正指向的是上游服务崩溃，还是 Traefik 自身的 health check 超时阈值设得太激进？以及，当docker ps显示容器 healthy，但 Traefik dashboard 却显示 backend 为DOWN时，该从哪个 socket 文件、哪个日志级别、哪个配置段开始切片排查？这才是一个资深从业者真正需要的“可执行知识”。
2. 整体架构设计与方案选型逻辑
2.1 为什么是 Traefik v1 而非 Nginx / HAProxy？
在 Ubuntu 20.04 上为 Docker 容器做反向代理，Nginx 和 HAProxy 当然可行，而且文档丰富、社区庞大。但它们与 Traefik v1 的根本差异，在于“服务发现”的自动化粒度。Nginx 需要你手动编写upstream块，再配合docker-gen或confd这类外部工具监听 Docker 事件并重写配置、触发 reload；HAProxy 类似，需依赖haproxy-consul或自研脚本。这些方案引入了额外的进程、配置文件、reload 时的连接中断窗口（哪怕只有 100ms），以及更复杂的故障树。
Traefik v1 把这个过程收归自身：它原生支持docker提供者，能直接通过/var/run/docker.sock监听容器的start/stop/die事件，并实时解析容器的 labels，动态构建路由规则与后端列表。整个过程无外部依赖、无配置文件生成、无 reload 动作——路由变更发生在毫秒级，且完全原子。我曾在一个电商大促压测中对比过：当每秒新增 20 个容器（模拟灰度发布），Nginx + docker-gen 方案平均 reload 延迟 320ms，期间约 1.7% 的请求返回 502；而 Traefik v1.7.32 在同等压力下，路由更新延迟稳定在 8–12ms，502 率为 0。这不是玄学，是它的事件循环模型决定的：v1 使用单 goroutine 顺序处理 Docker 事件队列，避免了并发写入配置结构体的风险，代价是牺牲了一点吞吐，换来的是确定性。
更重要的是，v1 的标签体系极度简洁。一个典型的 Nginx 手动配置可能需要 15 行（含 upstream、server、location、proxy_pass、proxy_set_header 等），而等效的 Traefik v1 labels 只需 4 行：
labels: - "traefik.enable=true" - "traefik.frontend.rule=Host:app.example.com;PathPrefix:/api" - "traefik.backend=app-backend" - "traefik.port=3000"这四行代码，Traefik 就能自动完成：创建 frontend（匹配 Host+Path）、关联 backend（app-backend）、设置负载均衡策略（默认 wrr）、探测健康端点（/health或traefik.port对应的端口）、生成 TLS 证书（如果启用了 Let's Encrypt）。这种“声明即实现”的体验，对快速迭代的 Docker 环境而言，是生产力的质变。
2.2 为什么锁定 Ubuntu 20.04 而非更新版本？
Ubuntu 20.04 是一个具有里程碑意义的 LTS（Long Term Support）版本，其生命周期将持续至 2030 年 4 月（标准支持至 2025 年 4 月，ESM 延伸支持至 2030 年）。这意味着两点：第一，它的内核（5.4）、systemd（245）、glibc（2.31）等底层组件高度稳定，极少出现 ABI 不兼容的更新；第二，它的软件源（archive.ubuntu.com）中，Docker CE 的官方包版本被严格锁定为5:20.10.21~3-0~ubuntu-focal，这个版本与 Traefik v1.7.x 的 socket 通信协议完全兼容。如果你尝试在 Ubuntu 22.04 上运行同样的配置，会遇到两个隐性陷阱：一是 22.04 默认启用 cgroup v2，而 Traefik v1.7 对 cgroup v2 的容器资源统计存在解析偏差，可能导致 health check 误判；二是 22.04 的 systemd 249 引入了更严格的ProtectHome=true默认策略，会阻止 Traefik 读取/root/.traefik/acme.json，除非你显式覆盖该选项。
此外，Ubuntu 20.04 的ufw（Uncomplicated Firewall）默认配置是“deny incoming, allow outgoing”，这对 Traefik 极其友好——你只需一条命令sudo ufw allow 80,443/tcp，就能安全暴露入口端口，无需像 CentOS 那样折腾 firewalld zone。而它的apparmorprofile 对 Docker daemon 的限制也恰到好处：既防止容器逃逸，又不干扰 Traefik 通过 socket 读取容器元数据。我在某次迁移评估中测试过：将同一套docker-compose.yml+traefik.toml从 20.04 复制到 22.04，仅因apparmor拒绝了capability dac_override，Traefik 就无法读取容器的Labels字段，所有路由均失效，日志里只有一行模糊的failed to get container labels: permission denied。这种细节，只有踩过坑的人才懂。
2.3 为什么坚持使用二进制安装而非 apt 包？
Ubuntu 20.04 的官方 apt 源中，并未收录 Traefik。你执行apt list | grep traefik会得到空结果。社区有人打包过第三方 deb，但这些包存在三个致命问题：第一，版本陈旧（多为 v1.6.x），缺乏 v1.7 中关键的retrymiddlewares 和buffering配置；第二，systemd 单元文件硬编码了/etc/traefik/traefik.toml路径，而实际生产中你很可能需要/opt/traefik/config/traefik-prod.toml这样的分环境路径；第三，最危险的是，这些 deb 包常将traefik二进制文件安装到/usr/bin/，并赋予root:root权限，一旦被恶意容器利用docker run -v /usr/bin:/host-bin ubuntu sh -c 'cp /host-bin/traefik /host-bin/traefik-backdoor'，就可能植入后门。
因此，我始终坚持“官方二进制 + 手动 systemd 单元”的组合。具体操作是：从 GitHub Releases 页面（https://github.com/containous/traefik/releases/tag/v1.7.32）下载traefik_linux-amd64（注意：v1.7.32 是最后一个正式 release，后续的 v1.7.33+ 仅为安全补丁，不公开发布），校验 SHA256（官方发布页提供 checksum），然后将其放入/opt/traefik/traefik，权限设为755，属主为root:traefik。这样做的好处是：二进制来源绝对可信；路径可控，避免污染系统目录；权限最小化，traefik用户仅对/opt/traefik/{config,acme,logs}有读写权，对/var/run/docker.sock仅有读权限（通过docker组授权）。这是一种“防御性运维”思维——不是假设系统干净，而是预设每个环节都可能出错，然后用权限隔离、路径隔离、进程隔离来构筑纵深防线。
2.4 整体通信链路与数据流向解析
理解 Traefik v1 在 Ubuntu 20.04 上的工作流，必须厘清四个关键实体间的交互关系：客户端 → Traefik（前端）→ Docker Daemon → 后端容器。这不是简单的请求转发，而是一套闭环的控制平面与数据平面分离的架构。
首先，客户端（如 curl 或浏览器）发起请求到http://app.example.com/api/users。Traefik 的前端（frontend）模块根据traefik.frontend.rule标签匹配该请求，确认其属于app-backend这个 backend。此时，Traefik 并不直接知道app-backend的 IP 和端口，它需要查询后端（backend）模块的“服务发现缓存”。这个缓存的数据，来自 Docker 提供者（provider）——它持续监听/var/run/docker.sock，当检测到新容器app-web启动时，立即读取其 labels，提取traefik.port=3000和traefik.backend=app-backend，并将app-web的 IP（Docker bridge 网络中的 172.18.0.x）与端口 3000 注册进app-backend的实例列表。
接着，Traefik 的负载均衡器（默认 weighted round robin）从该列表中选择一个健康实例（health check 通过），建立 TCP 连接，并将原始 HTTP 请求（包括 Host、User-Agent、Cookie 等 header）原样转发。这里有个关键细节：Traefik v1 默认会重写X-Forwarded-For、X-Forwarded-Proto等 header，但不会重写 Host header。这意味着，如果你的后端应用（如 Node.js Express）依赖req.headers.host做多租户路由，它收到的仍是app.example.com，而非容器的内部 IP。这是 v1 的设计哲学：尽量保持原始请求上下文，把决策权留给后端。
最后，响应数据流原路返回。但 Traefik 会在响应中注入X-Traefik-Backend（标识处理该请求的后端名）、X-Traefik-Backend-Server（标识具体容器名）等 debug header（可通过traefik.frontend.passHostHeader=true控制），这对线上排障至关重要。我曾用curl -I http://app.example.com快速定位过一次故障：响应头显示X-Traefik-Backend-Server: app-web-2，而docker ps | grep app-web却只看到app-web-1，立刻断定是app-web-2容器已死但 Traefik 缓存未刷新，执行docker rm -f app-web-2后问题消失。这种“所见即所得”的调试能力，是 Nginx 手动配置永远无法提供的。
3. 核心配置详解与实操要点
3.1 Traefik v1 配置文件（toml）结构拆解
Traefik v1 的配置核心是一个traefik.toml文件，采用 TOML 格式（比 YAML 更严格，不支持注释嵌套，但解析更快）。它分为两大块：全局配置（[global]）和提供者配置（[docker],[file]等）。下面是一个生产环境可用的最小完备配置，我将逐行解释其设计意图：
# traefik.toml debug = false logLevel = "INFO" defaultEntryPoints = ["http", "https"] [entryPoints] [entryPoints.http] address = ":80" [entryPoints.http.redirect] entryPoint = "https" [entryPoints.https] address = ":443" [entryPoints.https.tls] [retry] attempts = 3 backoff = "300ms" [acme] email = "admin@example.com" storage = "/opt/traefik/acme/acme.json" entryPoint = "https" onHostRule = true [acme.httpChallenge] entryPoint = "http" [docker] endpoint = "unix:///var/run/docker.sock" domain = "example.com" watch = true exposedByDefault = false swarmMode = false [file] filename = "/opt/traefik/config/rules.toml"第一行debug = false是铁律。v1 的 debug 模式会记录每一个 HTTP 请求的完整 body（即使 POST 数据长达数 MB），在高流量场景下，日志文件几小时内就能撑爆磁盘。我见过最惨的一次：某 API 网关开启 debug 后，/var/log/traefik/traefik.log在 37 分钟内增长到 42GB，触发df -h告警，而运维人员还在咖啡机旁——这就是为什么我把debug = false放在第一行，作为心理锚点。
logLevel = "INFO"是平衡点。ERROR级别太粗，会错过backend is unhealthy这类预警；DEBUG级别太细，淹没关键信息。INFO能清晰呈现：容器注册/注销事件、ACME 证书申请成功/失败、健康检查状态变更。例如，当你看到日志中Configuration received from provider docker: { ... }，就说明 Docker 提供者已成功加载新容器配置；而Backend health check failed: Get "http://172.18.0.3:3000/health": dial tcp 172.18.0.3:3000: connect: connection refused，则直指后端容器的健康端点未监听或防火墙阻断。
defaultEntryPoints = ["http", "https"]定义了所有 frontend 的默认入口。这意味着，即使你在容器 labels 中没写traefik.frontend.entryPoints=https，Traefik 也会自动将其路由到 https 入口。这是安全基线：强制 HTTPS 重定向。[entryPoints.http.redirect]块实现了这一点——所有 80 端口的请求，301 重定向到 443。注意，这里不是 rewrite，而是真正的 HTTP 重定向，客户端浏览器地址栏会变化，SEO 友好。
[retry]段是 v1 的隐藏王牌。它定义了当 Traefik 向后端发送请求失败时（如连接超时、5xx 响应），自动重试的策略。attempts = 3表示最多重试 2 次（首次 + 2 次重试）；backoff = "300ms"是退避时间，即第一次失败后等 300ms，第二次失败后再等 300ms。这个配置对微服务场景极其关键。比如你的订单服务依赖用户服务，而用户服务因 GC 暂停了 800ms，单次请求必然超时。没有 retry，用户会看到 502；有了 retry，Traefik 在 300ms 后重试，此时用户服务已恢复，请求成功。我在线上将backoff从"100ms"调整为"300ms"，502 率下降了 68%，因为更长的退避时间避免了在服务短暂抖动期发起雪崩式重试。
[acme]块处理 Let's Encrypt 自动证书。storage = "/opt/traefik/acme/acme.json"是证书存储路径，必须确保该文件权限为 600（仅 owner 可读写），否则 Traefik 启动会报错acme.json permissions too open。onHostRule = true是关键开关：它表示“只有当 frontend rule 明确匹配 Host 时，才触发 ACME 申请”。这避免了为PathPrefix:/api这类无 Host 的规则错误申请证书。[acme.httpChallenge]指定使用 HTTP-01 挑战，它要求 Traefik 在 80 端口临时开放一个/.well-known/acme-challenge/路径，由 Let's Encrypt 服务器访问验证。因此，你的防火墙必须放行 80 端口，且 Traefik 的 http entryPoint 必须启用。
[docker]是心脏。endpoint = "unix:///var/run/docker.sock"指向 Docker daemon 的 Unix socket。这里必须用unix://前缀，不能写成tcp://或省略，否则 Traefik 会尝试走 TCP 连接，而 Ubuntu 20.04 的 Docker 默认不监听 TCP。domain = "example.com"是 ACME 的基础域名，所有子域名（如app.example.com,api.example.com）都将基于此申请证书。exposedByDefault = false是安全基石：它意味着，除非容器显式声明traefik.enable=true，否则 Traefik 绝不为其生成任何路由。这杜绝了“测试容器意外暴露到公网”的事故。swarmMode = false明确告知 Traefik 当前是单机 Docker 模式，避免它错误地去查询 Swarm API。
[file]提供者是 v1 的灵活扩展点。它允许你将静态路由规则（如重定向、错误页面）放在单独的rules.toml文件中，与动态的 Docker 发现解耦。例如，你想把所有www.example.com的请求 301 重定向到example.com，就可以在rules.toml中写：
[frontends] [frontends.www-redirect] entryPoints = ["http","https"] backend = "redirect-backend" passHostHeader = true [frontends.www-redirect.routes.test_1] rule = "Host:www.example.com" [backends] [backends.redirect-backend] [backends.redirect-backend.servers.server1] url = "http://example.com"这种分离让配置更易维护：Docker 容器负责业务服务，file 提供者负责基础设施规则。
3.2 Docker 容器 Labels 的语义与陷阱
Traefik v1 通过容器 labels 实现“零配置服务发现”，但 labels 的书写有严格语义，一个字符错误就会导致路由失效。以下是生产环境中最常用、也最容易出错的 7 个 labels，我将逐一剖析其原理与实战案例。
1.traefik.enable=true
这是开关总闸。设为false或不设置，Traefik 完全忽略该容器。注意：true必须是小写，True或TRUE会被解析为字符串而非布尔值，v1 会静默忽略。我曾帮一个客户排查过连续三天的 503 错误，最终发现是 CI/CD 脚本里echo "traefik.enable=True" >> labels.env，一个大写 T 毁掉所有。
2.traefik.frontend.rule=Host:app.example.com;PathPrefix:/api
这是路由匹配的核心。Host:后跟域名，PathPrefix:后跟路径前缀，用分号;分隔。关键陷阱：分号后不能有空格。Host:app.example.com; PathPrefix:/api（分号后有空格）会导致整个 rule 解析失败，Traefik 日志里只有一行invalid frontend rule，没有任何位置提示。正确的写法是紧贴分号：Host:app.example.com;PathPrefix:/api。更安全的做法是，对复杂 rule 使用引号包裹：traefik.frontend.rule="Host:app.example.com;PathPrefix:/api"，避免 shell 解析干扰。
3.traefik.port=3000
这告诉 Traefik：“我的应用监听在容器内的 3000 端口”。它不是容器映射到宿主机的端口（-p 3000:3000 中的左边），而是容器内部的端口。很多新手会误写成traefik.port=80，以为要匹配-p 80:3000，结果 Traefik 去连接容器的 80 端口，而应用实际在 3000，必然 connection refused。正确逻辑是：Traefik 通过 Docker API 获取容器的 NetworkSettings.IPAddress（如 172.18.0.5），然后拼接http://172.18.0.5:3000/health做健康检查。因此，traefik.port必须与应用实际监听的端口一致。
4.traefik.backend=app-backend
这为后端服务命名。同名的所有容器（如app-web-1,app-web-2）会被聚合到同一个 backend 下，由 Traefik 自动负载均衡。命名必须唯一且合法：只能包含字母、数字、连字符-、下划线_，不能以连字符开头或结尾。traefik.backend=app-web是合法的；traefik.backend=app.web（含点号）会导致解析错误；traefik.backend=-app（开头连字符）会触发invalid backend name。我建议统一用小写字母+连字符，如user-service,payment-api，避免任何特殊字符。
5.traefik.frontend.passHostHeader=true
默认情况下，Traefik 会将请求的 Host header 替换为 backend 的 IP（如172.18.0.5），这对某些依赖 Host 的应用（如 WordPress 多站点、Rails 的config.action_mailer.default_url_options[:host]）是灾难。设为true，则原始 Host（app.example.com）被透传。但要注意副作用：如果后端应用做了 Host 白名单校验（如if req.Host != "app.example.com" return 403），而你又启用了多个 frontend rule（如Host:app.example.com;PathPrefix:/api和Host:legacy.app.example.com），那么legacy.app.example.com的请求也会带着Host:legacy.app.example.com过来，可能绕过白名单。这时，你需要在 backend 应用层做二次校验，而非依赖 Traefik。
6.traefik.docker.network=webnet
这是高级技巧。默认情况下，Traefik 会从容器的第一个网络（通常是bridge）获取 IP。但如果容器连接了多个网络（如bridge和自定义webnet），而你的应用只监听webnet网络，那么traefik.port对应的 IP 就必须来自webnet。traefik.docker.network=webnet显式指定网络名，确保 Traefik 读取正确的 IP。我在线上一个 Kafka Connect 集群中用过这个：Connect worker 容器同时在kafka-net（连 Kafka broker）和webnet（连 Traefik）中，traefik.docker.network=webnet让 Traefik 正确拿到webnet的 IP，避免了connection refused。
7.traefik.frontend.priority=100
当多个 frontend rule 可能同时匹配一个请求时（如Host:*.example.com和Host:app.example.com），priority 决定谁胜出。数值越大，优先级越高。Host:app.example.com的 priority 默认为 10，Host:*.example.com为 5。如果你想让泛域名规则兜底，就不需要改；但如果你有Host:staging.example.com和Host:app.example.com，且 staging 应该优先，就设traefik.frontend.priority=20。priority 是整数，范围 0–1000，v1 不会做范围检查，设成 9999 也不会报错，但超出 1000 后行为不可预测。
3.3 systemd 服务单元文件编写与权限控制
在 Ubuntu 20.04 上，将 Traefik 作为系统服务运行，必须编写一个健壮的 systemd 单元文件。以下是我经过 12 个生产环境验证的traefik.service，每一行都有其不可替代的作用：
# /etc/systemd/system/traefik.service [Unit] Description=Traefik Proxy v1.7.32 Documentation=https://docs.traefik.io/v1.7/ After=docker.service Wants=docker.service [Service] Type=simple User=traefik Group=traefik ExecStart=/opt/traefik/traefik --configFile=/opt/traefik/config/traefik.toml Restart=on-failure RestartSec=5 StartLimitInterval=60 StartLimitBurst=3 LimitNOFILE=65536 LimitNPROC=4096 EnvironmentFile=-/opt/traefik/config/env.conf ProtectSystem=full ProtectHome=true NoNewPrivileges=true ReadWritePaths=/opt/traefik/acme /opt/traefik/logs /opt/traefik/config CapabilityBoundingSet=CAP_NET_BIND_SERVICE [Install] WantedBy=multi-user.target[Unit]段中After=docker.service和Wants=docker.service是关键依赖。它确保 Traefik 总是在 Docker daemon 启动之后才启动，避免因/var/run/docker.sock不存在而失败。Wants表示强依赖，如果 Docker 启动失败，Traefik 也不会尝试启动。
[Service]段的User=traefik和Group=traefik实现了最小权限原则。你必须先创建该用户：sudo useradd -r -s /bin/false traefik。-r表示系统用户，-s /bin/false禁止登录。然后，将traefik用户加入docker组：sudo usermod -aG docker traefik，这样它才有权限读取/var/run/docker.sock（socket 文件属组为docker，权限为660）。
ExecStart指定了启动命令。注意：这里没有&后台符号，因为 systemd 要求Type=simple的服务必须以前台模式运行。如果 Traefik 进程自行 fork 到后台，systemd 会认为它已退出，反复重启。--configFile显式指定配置路径，避免 Traefik 在当前目录搜索traefik.toml，造成路径混乱。
Restart=on-failure是守护神。当 Traefik 因 panic、OOM killer 或配置错误退出时，systemd 会在RestartSec=5秒后重启它。StartLimitInterval=60和StartLimitBurst=3是熔断机制：如果 Traefik 在 60 秒内连续失败 3 次，systemd 将停止重启，防止“启动-失败-重启”的雪崩循环。这给了你人工介入的时间。
LimitNOFILE=65536和LimitNPROC=4096是性能调优。Traefik 作为反向代理，需要大量文件描述符（每个连接占用一个 fd）。Ubuntu 20.04 默认的nofile限制是 1024，远不够用。65536是保守值，足以支撑 10K 并发连接。NPROC限制进程数，防止 fork 爆炸。
ProtectSystem=full和ProtectHome=true是安全加固。前者将/usr,/boot,/etc挂载为只读，后者将/home,/root,/run/user挂载为不可访问。这意味着，即使 Traefik 进程被利用，也无法修改系统关键文件或读取用户家目录。
ReadWritePaths显式声明了 Traefik 唯一可写的路径：/opt/traefik/acme（存证书）、/opt/traefik/logs（写日志）、/opt/traefik/config（读配置）。其他所有路径均为只读，这是ProtectSystem的补充。
CapabilityBoundingSet=CAP_NET_BIND_SERVICE是精华。它授予 Traefik 绑定 1024 以下端口（如 80, 443）的能力，而无需以 root 身份运行。这是 Linux capabilities 的经典应用：传统上，只有 root 能 bind 80，但现在你可以让普通用户拥有这个单一能力，极大降低攻击面。没有这一行，Traefik 会报错listen tcp :80: bind: permission denied。
3.4 ACME 证书自动申请与故障诊断
Let's Encrypt 证书的自动申请是 Traefik v1 的亮点，但也是故障高发区。stream disconnected before completion: error sending request for url (http://127.0.0.1:57321/v1/responses)这类错误，90% 以上与 ACME 流程相关。下面我将带你穿透表象，直击本质。
首先，理解 ACME 的完整流程：1) Traefik 检测到新 Host（如app.example.com）；2) 它向 Let's Encrypt 的 staging 环境（https://acme-staging-v02.api.letsencrypt.org）发起注册；3) 生成密钥对，存储在acme.json；4) 发起 HTTP-01 挑战：在http://app.example.com/.well-known/acme-challenge/xxx放置一个 token；5) Let's Encrypt 服务器访问该 URL 验证所有权；6) 验证通过，颁发证书；7) 证书写入acme.json，Traefik 加载生效。
故障通常卡在第 4 或第 5 步。诊断的第一步，永远是看日志。执行sudo journalctl -u traefik -f，然后触发一次证书申请（如重启一个新容器）。你会看到类似这样的日志流：
level=info msg="Testing certificate renew..." level=info msg="Loading ACME data..." level=info msg="Validations succeeded, generating new cert..."
