ATS（Apache Traffic Server）的配置核心在于理清 records.config、remap.config 和 storage.config 这三个文件的协作逻辑，先把流量入口和缓存盘规划好，再谈细粒度调优。
近两年随着边缘计算和CDN自建需求增多，ATS又重新回到不少运维团队的视野，相比Nginx和Varnish，ATS在原生代理协议支持和多租户隔离上确实有独到之处，但它的配置体系也劝退了不少新手配置文件散落在多个目录，参数命名风格自成一派，网上能搜到的中文实战资料又大多是老版本的内容，这篇文章就按实际排错和上线的顺序，把 ATS 配置的骨架讲清楚。
ats配置文件详解：先摸清家底再动手
业内专家指出，绝大多数 ATS 配置问题都出在“不知道某个行为该去哪个文件里改”，ATS 的配置体系不像 Nginx 那样集中在一个 nginx.conf 里，而是按照功能拆成了多个文件，统一放在 etc/trafficserver/ 目录下，这个设计初看繁琐,但熟悉之后会发现它其实是为了热加载和权限隔离服务的。
这几个文件各管一摊
records.config：ATS 的“总开关”，控制进程级行为，比如监听端口、线程数、超时时间、日志开关。remap.config：反向代理的“路由表”，定义外部请求打到哪个内部服务，也就是 URL 重写和流量分发规则。storage.config：告诉 ATS 把缓存数据写到磁盘的哪个位置,划多大空间。cache.config：细粒度控制哪些请求能缓存、哪些必须回源，优先级高于 records.config 里的全局缓存开关。plugin.config：加载插件，比如鉴权、改写响应头、CPU 限速等。ssl_multicert.config：绑定 TLS 证书和域名，处理 HTTPS 卸载。hosting.config：多租户场景下的资源隔离配置,比如给不同客户划分缓存空间配额。
records.config 里最值得优先改的几个参数
初次接触 ATS，面对 records.config 里上千行配置往往会懵，不用全看,抓几个关键项就能让系统跑起来：
proxy.config.http.server_ports：监听端口，默认是 8080，如果做标准 80 端口代理，改成80就行。proxy.config.http.insert_request_via_str和insert_response_via_str：控制是否在请求和响应头里插入 Via 字段，排查链路时建议先改成1（开启）。
proxy.config.http.cache.http
proxy.config.http.transaction_no_activity_timeout_in：请求读超时，默认 30 秒，视频流场景建议调大到 120 秒,避免大文件传输中途被掐断。proxy.config.http.keep_alive_timeout_in：长连接保持时间，默认 15 秒，如果后端服务处理慢，适当调高到 30 秒能减少重复建连的开销。
改完后必须执行 traffic_ctl config reload 让配置生效，而不是重启进程，reload 只加载变更项，对在线连接的影响极小，这是 ATS 优化得比较好的地方。
ats缓存配置核心要点：多级缓存与淘汰策略的实战配合
不少朋友把 ATS 配好后发现缓存命中率总上不去，一问才知道压根没管过 storage.config，所有数据全写在默认的 /var/cache/trafficserver 里，这个目录通常和系统盘共用，空间小不说，还容易因为日志刷盘抢占 I/O。
storage.config 的容量规划思路
storage.config 每行代表一个缓存存储单元,常见的配置方式有整盘挂载和文件挂载：
/dev/sdb1 256G /var/cache/ats_extra 64G
第一行是裸设备分区，性能最好，适合缓存命中压力大的生产环境；第二行是普通文件路径，适合先跑通流程的测试环境，需要注意一点：cache.config 里对特定 URL 的缓存策略，其优先级永远高于 records.config 里的全局设置。
cache.config 的几个高频使用场景
- 对 API 接口不做缓存,避免返回脏数据：
dest_domain=api.example.com action=never-cache
- 强制缓存无默认缓存头但实际变化很小的静态资源：
url_regex=http://img\.example\.com/.\.(png|jpg) action=ttl-in-cache=1d
- 对带 query string 的 URL 谨慎缓存,防止参数不同但响应头相同导致串数据：
url_regex=/live/. action=ignore-no-cache
这里有个容易踩的坑：配置里没写 cache.config，不代表所有请求都会进缓存。 ATS 遵循 RFC 2616 的基本语义，只有响应的 Cache-Control 或 Expires 头允许缓存时才会存储，测试缓存是否生效的最快方式是用 curl -I 查看响应头里的 X-Cache: hit
或 miss 字段，hit 代表命中，miss 代表回源。
ats反向代理配置：从零搭建一个带缓存的静态资源加速入口
拿最常见的需求举例：手头有一台部署在成都机房的源站服务器，跑的是 Nginx 静态文件服务，希望用 ATS 做前端缓存加速，同时隐藏源站 IP,具体操作路径如下：
第一步：安装并调整全局监听
以 CentOS 7 和 8 为例，官方源里就有 ATS，版本可能旧一些，但核心配置逻辑不变，装好后先改 records.config：
CONFIG proxy.config.http.server_ports TEXT 80 443:ssl CONFIG proxy.config.http.insert_response_via_str INT 1 CONFIG proxy.config.http.insert_request_via_str INT 1
这里把 HTTP 和 HTTPS 都打开，SSL 证书的位置留给 ssl_multicert.config 去填,保持解耦。
第二步：写 remap.config 路由规则
目的：外部访问 http://cdn.你的域名.com/2026/ 开头的资源，实际回源到 http://192.168.1.10:8080/2026/ 拉取数据,配置写法如下：
map http://cdn.你的域名.com/2026/ http://192.168.1.10:8080/2026/ map http://cdn.你的域名.com/health http://192.168.1.10:8080/health
注意第二行的健康检查路径，健康检查的 URL 建议单独映射，不要写在泛匹配里，否则会被缓存策略误伤。 写完 remap.config 后执行 traffic_ctl config reload，再用 curl -H "Host: cdn.你的域名.com" http://127.0.0.1/2026/test.jpg -I 验证响应头。
第三步：确认 X-Cache 状态
如果返回的响应头里 X-Cache: miss，说明缓存没有启用或者还没写入，多请求几次同一个 URL，第二次应该变成 hit，如果一直是 miss，回到 records.config 检查 proxy.config.http.cache.http 是否为 1，以及源站响应头是否携带了 Cache-Control: max-age。
另外补充一个实际中容易忽略的点：反向代理场景下，ATS 默认会把请求头里的 Host 原样转发给源站。 如果源站是 IP 访问，需要在 remap.config 里加 @pp=ip 参数，否则源站 Nginx 会因为 Host 头不匹配而拒绝请求。
ats和nginx选哪个更合适：业务场景决定技术选型
很多团队在选型时会纠结到底用 ATS 还是 Nginx 来做缓存层，这个问题的答案不绝对,但有几个明确的判断标准可以参考。
根据业务规模来分：
- 站点数量少（少于 10 个）、规则简单，Nginx 的
proxy_cache完全够用，配置直观，社区资料也丰富,符合多数中小团队的维护习惯。 - 需要处理海量小文件、高并发连接，或者要用到 ICP（Internet Cache Protocol）和 ESI（Edge Side Includes）这类原生缓存协议，ATS 的架构优势就体现出来了，ATS 的 event loop 模型在保持大量并发连接时内存占用比 Nginx 的 worker 模型更可控，而 cache 引擎对磁盘 I/O 的分层处理也更细腻。
行业共识认为，快和稳之间通常要做一个取舍，Nginx 胜在灵活和轻量，ATS 胜在原生代理语义和横向扩展能力，如果只是为了防盗链和简单的动静分离，用 Nginx 就足够了，没必要引入额外维护成本；如果目标是搭建一个独立于业务代码的边缘缓存层，并且希望后续对接 CDN 联盟，ATS 的投入产出比会更理想。
常见问题快查
ATS 配置完 reload 后不生效是什么原因？
优先检查 records.config 里有没有写错参数名，ATS 对配置项名称是大小写敏感的，而且不会像 Nginx 一样在 nginx -t 阶段就报告错误，配置错误往往要等请求进来才会暴露，执行 traffic_ctl config status 能查看当前加载的配置版本，再配合 /var/log/trafficserver/diags.log 里输出的 ERROR 级别日志定位具体行号。
remap.config 支持正则表达式吗？
支持，但不推荐一来就上复杂正则，remap.config 的匹配逻辑比较朴素，按顺序从上往下找第一个匹配项，如果多个规则存在前后重叠，前面的规则会掩盖后面的规则，建议用显式的路径前缀匹配，减少调试成本，需要做正则改写时，考虑用 @plugin=regex_remap.so 配合独立配置文件的方案,可读性和维护性都会好很多。
缓存目录空间写满了会怎样？
ATS 不会因为缓存盘满而崩溃，它的 disk 管理进程会周期性地扫描 storage 里的使用率，当达到 proxy.config.cache.high_water_mark（默认 90%）时触发强制淘汰，直到降到 low_water_mark（默认 85%）以下，这个机制是平滑的，但要注意如果磁盘本身损坏，ATS 会放弃整个缓存盘并回源，diags.log 里会出现 cache disk failed 的段错误信息，需要立即更换存储设备并执行 traffic_server -C 清空缓存目录重新初始化。