本地 Compose 里 web、api、admin 各占一个端口，再加一层 TLS 和路径分流，Nginx 的 server / location 块很快散成几份互相引用的片段。有人换自动发现式入口，却在文档目录里先撞上 Hub、API Gateway 一堆产品名，分不清「开源反代本体」从哪读起。Traefik 文档首页 把自己写成 Application Proxy：先替系统收请求，再识别该交给谁，并在基础设施变化时动态更新路由。下面只抠它反复出现的四个概念，不写怎么打穿内网，也不复述证书申请专文。
请求先撞 Entrypoint
文档把 Entrypoints 说成进入 Traefik 的网络入口：定义监听端口，以及听 TCP 还是 UDP。可以把它想成「对外露哪几个门」。HTTP / HTTPS 常见是 80 / 443，内部调试口另开也行。先把「流量从哪进来」和「进来之后怎么匹配」拆开。很多初次配置的人把域名规则和端口写在同一坨里，改端口时连带改路由，回滚时不知道动了哪一层。
Router 负责接上 Service
Routers 的职责是把进来的请求接到能处理它的服务。过程中可以挂 middleware，在转发前改请求或做别的动作。匹配规则（主机名、路径前缀等）落在这一层，而不是散落在每个后端容器的环境变量里。Services 则负责「怎么真正够到后面的实例」：负载到哪些地址、用什么策略。文档把这三层排成一条流水线：Entrypoint 收包 → Router 判定与加工 → Service 送达应用。读配置时按这个顺序对，比按文件名跳着看省事。
Provider 是规则从哪来的
Providers 指基础设施一侧：编排器、容器引擎、云厂商、键值存储等。Traefik 通过查这些 Provider 的 API，找出和路由相关的信息。检测到变化就动态更新路由。文档强调这件事发生在实时路径上，不必为改一条规则整进程重启、切断已有连接。Docker / Kubernetes 场景里，常见做法是用标签或 Ingress 资源描述「这个服务要挂到哪条路由」，由 Provider 喂给上面那三层，而不是手写一份永远过期的静态表。静态文件 Provider 也有，适合规则很少、又不想绑编排器的情况。心智模型不变，只是「谁在喂配置」换了来源。
和「写死一份反代配置」差在哪
传统静态反代往往是：人改配置文件 → 校验 → reload。服务上下线要同步改那份文件。Traefik 的卖点写在首页：自动发现相关配置，按基础设施里的信息决定谁服务哪个请求。代价是你得接受「真相在标签 / CRD / 键值里」，排障时要会对照 Dashboard 或 API 看当前生效的 Router / Service，而不是只盯着仓库里某份 yaml 的旧快照。证书、自动 HTTPS 若你更熟另一条入口，站内有一篇 Caddy 自动 HTTPS 可对照。本文只停在路由模型，不展开签证书流程。
入门时容易混的两处
一是把 middleware 当成 Service。中间件挂在 Router 上，改的是「转发前的请求或响应行为」。Service 才指向后端。二是一上来就钻 Hub / AI Gateway 产品页。开源文档首页已经声明：可以从服务发现和路由起步，需要时再叠 API 管理等能力。个人或小团队先把 Entrypoint → Router → Service → Provider 跑通，比同时啃商业对照表更不容易迷路。
本地若只是两个静态站点，继续用熟悉的反代完全够用。容器和主机名开始按周增减、重复规则越来越痛时，再按官网概念图拆自己的配置，通常比「整份 Nginx 翻译成 Traefik」少返工。你那边是 Docker labels 先试，还是直接上 Kubernetes Ingress / CRD？