所有功能
您可能需要坐下来慢慢看。

此颜色的功能由可选插件提供。

概述

Caddy 本质上是一个配置管理系统,可以运行各种应用程序,如 HTTP 服务器、TLS 证书管理器、PKI 设施等。它可以通过称为配置模块的插件进行扩展。

Caddy 拥有灵活而强大的 HTTP 反向代理、在线配置 API 和健壮的生产级静态文件服务器,默认情况下通过自动 TLS 证书为所有站点提供 HTTPS 服务。

整体程序技术规格

编程语言

语言选择对 Web 服务器至关重要。语言影响开发速度和便利性、性能、测试、部署复杂性、生态系统可靠性、依赖关系、工具、错误处理和可靠性等。Go 在这些领域都提供了强大的优势,允许快速开发、健壮的生产性能和高可扩展性。
Go

内存安全保证

大多数服务器(NGINX、Apache、HAProxy 等)及其依赖项都是用 C 编写的,容易受到灾难性内存安全漏洞(如缓冲区溢出)的影响,就像 Heartbleed 漏洞一样。像 Caddy 这样的 Go 程序对整类安全漏洞都具有免疫力。
强大

构建产物

Caddy 直接编译为原生 CPU 指令。不需要解释器;许多指令都是针对架构优化的。静态二进制文件也更安全,因为没有动态链接。
平台原生静态二进制文件

运行时依赖

Caddy 是静态编译的。动态链接的应用程序在生产环境中容易出现问题,并且可能不太安全,因为共享可执行资源从系统各处加载。通常,Caddy 二进制文件不一定需要外部库 — 甚至不需要 libc。

编译时间

在消费级硬件上,标准 Caddy 构建只需几秒钟即可完成。这对于快速迭代、插件开发和低成本部署至关重要。用 C/C++ 编写的其他服务器可能需要几分钟。
~30 秒冷构建,
~2 秒热构建

部署环境

Caddy 几乎可以部署在任何地方,并且有多种部署方式。通常,升级就像替换二进制文件一样简单。
  • 命令行界面
  • 系统服务
  • 容器
  • Kubernetes
  • 嵌入式

供应链和发布

Go 模块验证我们依赖项的完整性,我们对发布产物进行加密签名,这样您就知道可以信任什么。
加密验证

操作系统

Caddy 可以在 Go 编译的所有主要平台上运行。
  • Linux
  • Windows
  • macOS
  • FreeBSD
  • OpenBSD
  • NetBSD
  • Android

微架构

在众多 CPU 平台上使用原生代码运行 Caddy。
  • x86 (i386, i686)
  • x86-64 (AMD64)
  • ARM
  • ARM 64 (AArch64)
  • MIPS
  • MIPS64[LE]
  • PPC64[LE]
  • RISCV64
  • S390X
  • Apple Silicon (Apple ARM; M1, M2 等)

正则表达式引擎

Caddy 的正则表达式语言基于 Thompson NFA,并且比 PCRE 有许多性能改进。它保证运行时成本线性增长而不是指数增长。这在评估不可信输入时非常理想。

RE2 语法

RE2

并发模型

Go 的运行时使用称为 goroutine 的轻量级用户空间线程,以比操作系统更智能的方式优化 CPU 时间调度。Caddy 利用所有 CPU 核心,轻松处理每秒数十万个请求。
Goroutine (epoll + kqueue)

插件模型

Caddy 可以通过编译时插件进行扩展,这些插件编译为原生代码,在部署或系统升级期间不会被破坏。由于没有 IPC 或 RPC 调用,Caddy 扩展与原生代码性能相当。
编译时静态

高级功能

配置更改

通过零停机优雅重载,可以在 Caddy 运行时更改其配置。它是可编程/可脚本化的,支持强大的自动化。
  • RESTful HTTP API
  • 配置文件
  • 安全远程访问

应用模块

顶级配置结构称为应用模块或 Caddy 应用。它们提供了 Caddy 的大部分功能。任何人都可以编写应用模块,Caddy 内置了几个标准应用。
  • HTTP
  • TLS
  • PKI
  • 事件
  • 原始 TCP 和 UDP
  • SSH
  • PHP
  • 动态 DNS
  • 安全
  • 进程监控
  • 性能分析

日志

所有 Caddy 模块都使用 Caddy 的集中式日志设施。Caddy 的日志可以配置格式、详细程度、输出等。
  • 分级
  • 结构化
  • 高效,零分配
  • 可扩展
  • 删除、过滤、编辑和审查字段
  • IP 掩码
  • 哈希值
  • 正则表达式替换

存储

资产和状态,包括证书和 OCSP 装订,存储在可配置的存储后端中。实际上,配置了相同存储的多个 Caddy 实例被视为集群的一部分,可以自动协调。
  • 文件系统
  • 嵌入式(内存中)
  • Postgres
  • Redis
  • Vault
  • Consul

命令行界面

Caddy 的 CLI 不仅有用—它还很有帮助。虽然大多数服务器 CLI 只是运行进程和重载配置,但 Caddy 的 CLI 更进一步,帮助您轻松管理现代 Web 服务器。

插件可以注册自己的子命令来扩展 Caddy 的 CLI。

命令帮助

如果您拼错命令或标志、缺少参数或不知道子命令,会自动打印帮助文本。您还可以使用 caddy help-h 访问整体命令帮助或子命令帮助。
内置,自动(也可以生成 man 页面)

管理 API 包装器

几个子命令使用管理 API 端点与 CLI 一起使用,帮助您执行常见任务,如从文件加载配置或停止服务器。
  • 将配置转换为 JSON
  • 启动服务器,可选择使用配置
  • 优雅重载配置
  • 停止服务器

二进制工具

由于 Caddy 的自定义构建非常常见,因此有几个命令可以帮助您管理和获取有关构建的详细信息。
  • 详细的构建元数据
  • 列出已安装的配置模块
  • 列出依赖项
  • 添加和删除插件包
  • 打印版本
  • 升级 Caddy 二进制文件

配置工具

如果您选择使用配置文件,Caddy 的 CLI 可以帮助您管理它们。
  • 格式化 Caddyfile
  • 验证配置
  • 列出依赖项
  • 添加和删除插件包
  • 打印版本

模块工具

模块可以注册自己的子命令,提供可以在没有配置文档的情况下使用的常见功能。
  • 静态文件服务器
  • HTTP 反向代理
  • 静态 HTTP 响应(可模板化)
  • 存储导入/导出(备份/恢复)
  • 为 HTTP 基本认证生成密码哈希
  • 导出文件浏览模板

集成工具

几个子命令可以帮助您将 Caddy 集成到您的 shell 环境中。
  • 生成 shell 补全脚本
  • 打印环境
  • 生成 man 页面
  • 将 Caddy 管理的根 CA 安装到信任存储中
  • 从信任存储中删除 Caddy 管理的根 CA

系统信号

Caddy 支持常见的操作系统信号/中断,每个信号的行为都有细微差别。

信号文档

  • INT(优雅停止)
  • QUIT
  • TERM

退出代码

无论 Caddy 是成功退出还是出错,退出代码都可以给您的进程监控器或脚本提供如何处理该情况的提示。

配置

我们设计 Caddy 时,使其配置不仅提供对功能的访问,而且它本身就是一种功能

不再争论哪种配置文件格式最好:使用您想要的任何格式!Caddy 的配置适配器允许您使用您喜欢的任何配置格式。

原生配置格式

Caddy 的原生配置格式无处不在:它在几乎每个操作系统、平台、编程语言和 API 生态系统中都有工具。几乎所有其他格式都可以转换为 JSON,它在人类可读性和可编程性之间取得了平衡。您会发现它是您的 Web 服务器的强大盟友。
JSON

配置适配器

您始终可以用其他格式编写配置,使用配置适配器,Caddy 会隐式地将其转换为 JSON,这样您就可以使用您喜欢的方式。
  • Caddyfile
  • JSON 5
  • JSON-C
  • NGINX Conf
  • YAML
  • CUE
  • TOML
  • HCL
  • Dhall
  • MySQL

人性化配置

Caddyfile 是大多数用户手动编写 Web 服务器配置的最喜欢的方式,因为它的语法宽容,同时也设计有易于读写结构。它会自动转换为 JSON。
Caddyfile

导出

Caddy 的管理 API 允许您通过简单的 GET 请求以 JSON 格式访问当前配置。

配置 API

Caddy 通过 API 端点接收其配置,该端点可以接受 JSON 或它有任何配置适配器的其他格式。 Caddy receives its configuration through an API endpoint, which can accept JSON or any other format it has a config adapter for.

Config files

If you prefer normal shell commands for managing configuration, Caddy's CLI wraps the API endpoints for you.

Automatic HTTPS

Our flagship feature, powered by CertMagic. Caddy is the first and only major server that enables HTTPS by default, and automatically procures and renews certificates for all your sites.

Fully-native, integrated auto-HTTPS is far superior to any solution that requires external tooling or cron jobs. Caddy's certificate maintenance is the best in the industry because it is more robust, reliable, and scalable than any other solution. Caddy simplifies your infrastructure instead of complexifying it.

Sure, you can try deploying 100,000 sites with Certbot and a cron job—but if that doesn't fall over by itself, the web server will. Only Caddy is designed to massively scale TLS certificates both horizontally and vertically.

Never manually generate a CSR again. Never click a link in an email to download a certificate. Never (mis)configure your web server to use them. Never miss reminders to renew your certificates, one-by-one, every few months before they expire. You won't even have to think about certificates or TLS.

It's truly automagic.

Compliance

Caddy's TLS defaults are secure without any additional configuration, and passes compliance tests across various industries.
  • PCI DSS compliant
  • NIST compliant
  • HIPAA compliant
  • Industry best practices

On-Demand TLS

Serving domains that aren't yours? Or have lots of them? No problem! With just a few lines of config, On-Demand TLS gets certificates dynamically during TLS handshakes, scaling your deployments to tens of thousands of certs. This functionality is exclusive to Caddy.

Certificate issuers

Get certificates from any issuing authority in a way compatible with them. Certificate issuers take a CSR and return a certificate resource. Most sites will simply use ACME to get certificates. But Caddy can also issue its own self-signed certificates for internal use, testing, or development. Caddy's issuer sources are pluggable, so Caddy can automate certificates from any issuer modules.
  • ACME
  • Internal (self-signed)
  • Microsoft Active Directory Certificate Services

Certificate managers

Unlike issuers, which take a CSR and return a certificate that Caddy has to manage, certificate managers are modules that can return always-valid certificates on-demand; that is, they are managing the certificates for us. Caddy can get interface with HTTP endpoints or Tailscale to get certificates in this manner, with other ways available through plugins.
  • HTTP
  • Tailscale

Cluster coordination

Across all Caddy instances configured with the same storage, Caddy automatically coordinates and shares resources across the cluster. This includes certificate operations and the certificates themselves, OCSP staples, and session ticket keys. This results in reduced latency for your clients and higher scalability.
  • Obtaining & renewing certificates
  • Loading existing certificates
  • OCSP staples
  • Session ticket keys (STEKs)

Redirect HTTP to HTTPS

By default, HTTP requests will be redirected to HTTPS.
Automatic redirects

OCSP

OCSP indicates when certificates are revoked. Servers should staple OCSP responses to certificates to provide clients with better security and privacy. Caddy is the first and only server to do this automatically and by default. It also caches responses to weather OCSP responder outages, and shares them across its cluster. This can all be disabled if needed.
Automatic OCSP stapling with caching

Must-Staple

Caddy can obtain certificates that force OCSP stapling if the CA supports it. This may grant a higher degree of security in the case of revocation.

Revocation handling

Revoked certificates automatically get replaced. Because Caddy staples and refreshes OCSP responses, it can detect if your certificate has been revoked, and if so, it will replace it with a fresh certificate.

Session ticket hardening

TLS connections are pointless if an attacker steals the key to encrypt session tickets. Caddy has been academically cited as the only server to rotate these keys regularly to limit attack windows.
Automatic STEK rotation

Key types

You can customize the type of key used for your certificates.
  • Ed25519
  • ECDSA P256
  • ECDSA P384
  • RSA 2048
  • RSA 4096

Certificate lifetimes

Most ACME clients assume 90-day certificates, or don't expect certificates shorter than 7 days. Caddy can successfully manage certificates with lifetimes on the order of hours and minutes.

Instead of hard-coding a certain age before renewing, Caddy computes the age relative to the lifespan of each certificate, called a Renewal Window Ratio. By default, Caddy renews certificates after 2/3 of their usable lifetime. This ratio works for most validity periods, but can be adjusted.

Any lifetime

Intelligent error handling

If Caddy can't get a certificate, errors are logged and Caddy will backoff exponentially and retry as long as needed until it succeeds (typically up to 30 days but could be longer). Caddy makes every reasonable effort to keep your certificate renewed.
Exponential backoff

Built-in throttling

Caddy conforms to best practices and doesn't blast CAs with requests for certificates; instead, each order is carefully timed to avoid overwhelming CA servers.

ACME

Caddy's ACME client is best-in-class, with higher reliability and more production experience than any other integrated ACME client available today. Caddy has been using ACME since before the public availability of Let's Encrypt, and Caddy works with any ACME-compatible CA.

Compatibility

Some ACME clients are only tested with Let's Encrypt. Caddy is guaranteed compatible with all ACME-capable CAs.
All RFC 8555-compliant certificate authorities, such as:
  • Let's Encrypt
  • ZeroSSL
  • Google Trust Services
  • BuyPass
  • DigiCert
  • GlobalSign
  • SSL.com
  • Smallstep

Test endpoints

By default, Caddy will fall back to a CA's test or staging endpoint (if there is one) after a failed attempt at getting a certificate to avoid hitting CA-enforced production rate limits. This could also be an ACME server you set up solely for the purpose of validating DNS configurations.
Let's Encrypt (others configurable)

External account binding

Optionally configure External Account Binding (EAB) to enable Caddy to work with CAs that require you to have a separate account with them.

Challenge types

Caddy supports all major ACME challenge types for Web PKI and can also be extended to support others.
  • HTTP-01
  • TLS-ALPN-01
  • DNS-01

Alternate challenge ports

While certain ACME challenges must use the standardized ports 80 and 443, Caddy supports listening for these on alternate ports if you are forwarding them through a router.
  • HTTP (default 80)
  • TLS-ALPN (default 443)

Smart challenge selection

Caddy learns what challenge types are most likely to succeed and tries those first. For example, if port 80 is blocked, it will learn to prefer the TLS-ALPN challenge which does not use port 80.

DNS challenge integrations

The DNS challenge is the only one that does not require the CA being able to access your server. Solve the DNS challenge with integrations for dozens of DNS providers via libdns. This list is incomplete; see the full list of DNS providers.
  • ACME-DNS
  • AliDNS
  • Cloudflare
  • DigitalOcean
  • DNSPod
  • DuckDNS
  • DynDNS
  • EasyDNS
  • Gandi
  • GoDaddy
  • Google Cloud DNS
  • Hetzner
  • Linode
  • Name.com
  • Namecheap
  • Namesilo
  • Netlify
  • OVH
  • Porkbun
  • PowerDNS
  • RFC 2136
  • Route 53
  • Scaleway
  • Vercel
  • Vultr
  • See all...

Trusted CA certificates

Optionally configure root certificates you trust when interacting with your CA of choice; this is helpful for internal PKI where trust is established without public CAs.

Preferred chains

When the CA offers multiple certificate chains, Caddy gives you the ability to customize which one to download and use.
  • Smallest
  • CommonName of root
  • CommonName of any

Renewal scheduling

Caddy chooses conservative timeframes to renew certificates, and also takes guidance from the ACME CA if it provides ACME Renewal Information (ARI).
  • Internal
  • ARI

HTTP server

Caddy's HTTP server is one-of-a-kind: powerful, extensible, efficient, and modern.

HTTP versions

Caddy's HTTP server supports all major versions of HTTP and enables them by default (except H2C which is insecure, but available). You can customize exactly which versions you want to serve.
  • HTTP/1.1
  • HTTP/2
  • HTTP/2 over cleartext (H2C)
  • HTTP/3

HTTPS

Caddy's flagship feature is enabling HTTPS automatically and by default. You can control how it works or disable aspects: HTTP redirects, certificate management, certain hostnames, etc.
Automatic

Listen interfaces

Each HTTP server can bind to one or more sockets and network interfaces. For ports, you can specify specific host interface or all interfaces with just a port. All varieties of unix sockets are also supported.
  • TCP
  • UDP
  • Unix sockets

Listener wrappers

Listeners can be wrapped by modules that operate at the connection-accept level.
  • Redirect HTTP on HTTPS port
  • PROXY protocol
  • Tailscale

Timeouts

Setting timeouts is an important defensive measure for production environments, but must be tuned carefully to accommodate legitimate slow clients with large downloads or uploads.
  • Read timeout
  • Read HTTP header timeout
  • Write timeout
  • Idle timeout
  • TCP keepalive interval

Full duplex communication

Concurrent reading and writing of HTTP/1 is not supported by all clients, but can be enabled for certain clients and applications that require it.
  • Configurable for HTTP/1
  • Default for HTTP/2

Error handling

Caddy gives you full control over handling errors to give you clients the best/desired experience.
Custom error routes

TLS termination

Terminate TLS (formerly "SSL") with sensible defaults that you can customize to give you fine-grained control over TLS handshakes. You can assign policies to clients based on various factors such as ServerName (SNI) or remote IP.
  • TLS 1.2
  • TLS 1.3
  • Client authentication (TLS mutual auth; mTLS)
  • Client auth modes: request, require, verify if given, require and verify
  • Cipher suites
  • Curves
  • ALPN
  • Limit protocol versions
  • Default SNI
  • Fallback SNI

Cross-site security

Caddy often serves multiple sites on the same socket, so Caddy automatically enables protections to keep your sites safe if any of them have TLS client auth enabled.
Verification that TLS ServerName and HTTP Host header match

Access logs

Enable zero-allocation, structured access logs for the ultimate understanding of client requests and responses. Customize using Caddy's built-in logging configuration or the use of third-party modules.
  • More useful than Common Log Format (CLF)
  • Request headers (except sensitive fields)
  • Response headers
  • Remote IP
  • Latency

Observability

Your web server can be monitored using standards-compatible metrics.
Prometheus metrics, open telemetry

Request handling

The HTTP server handles requests using custom routes consisting of specific handlers in the order you define. A separate error route can be defined for custom error handling. You have a high degree of flexibility with HTTP handling. See below for available HTTP handler modules.
Composable routes (and separate error handling routes)

Request filters

Apply handlers to only certain requests using matchers, which classify requests based on various properties. Matchers are also used for filtering. They are extensible and pluggable, so there's no limit to how specific and custom your routes can be! Some matchers support regular expressions. All are quite fast. And matchers can be combined in sets so they can be joined with AND, OR, and NOT logic.
  • Host
  • Path
  • Method
  • Headers
  • Protocol
  • Remote IP
  • Arbitrary CEL expression
  • File (existence, size, modify date)
  • HTTP route variable
  • Logical NOT
  • Geolocation
  • Remote host

HTTP handlers

Handlers are modules that can be composed together to handle incoming requests precisely the way you want. Handler modules are, like the rest of Caddy, extensible and pluggable. It is not really feasible for us to list all the handlers here.

In practice, handlers are paired with matchers which filter or classify requests based on various properties such as their path, headers, query string, method, and more. This allows you to selectively apply any and all of these handlers to certain requests.

ACME server

Right out of the box, Caddy ships with a production-ready ACME server, perfect for your internal PKI. Automate mTLS certificates inside your infrastructure with ease. Powered by Smallstep libraries.

Authelia

Secure routes with authentication using Authelia.

Authentication

Authenticate users with an extensible authentication module. Extended by auth providers, this handler returns an error if the user cannot be authenticated by any configured providers. HTTP basic auth is included standard, and unlike other servers, passwords are hashed when setting up basic auth (since it's essentially a password database), enhancing security.
  • HTTP Basic authentication
  • JWT
  • Discord
  • Forms
  • SAML

Advanced auth

With a full suite of authentication and authorization features, the caddy-security module provides a variety of robust auth solutions.
  • Form-based
  • Local
  • Basic
  • LDAP
  • OpenID Connect
  • OAuth 2
  • SAML

Cache

Easily enable caching to serve more clients and increase performance. This cache module is compliant with RFC 7234 and supports tag-based cache purge, distributed and local storage, key generation tweaking, and more. Multiple backends are supported!
  • Badger
  • Etcd
  • NutsDB
  • Olric
  • Redis

Encode

Compress, encode, or otherwise transform HTTP responses on-the-fly with pluggable encoding modules. Compressing responses is as easy as a single line of configuration, and encodings won't be applied to responses that are already in a compressed format or are too small to be worthwhile.
  • Gzip
  • Zstandard (zstd)
  • Brotli

File server

A powerful, flexible, and efficient static file server that is described in detail below.

Go package vanity paths

A simple handler that implements vanity import paths for Go packages.

gRPC-Web bridging

Bridge/convert gRPC-Web requests to gRPC for your backend app.

Header manipulation

Modify HTTP request and response headers. Adding, setting, deleting, and replacing substrings in header fields is fast, but regular expressions are also supported for advanced use. Response header manipulations can be deferred until the very end when the response starts to be written, and can even be made conditional on response status code or header values.
  • Add
  • Set (overwrite)
  • Delete
  • Substring replace

Image filtering

Perform adjustments on images on-the-fly.
  • Crop
  • Fit
  • Flip
  • Resize
  • Rotate
  • Sharpen

Map

Assign variable/placeholder values based on input values; similar to a lookup table.

Mercure

Make your Caddy instance a Mercure hub: an open, easy, fast, reliable and battery-efficient solution for real-time communications.

Metrics

Expose a /metrics endpoint for use with Prometheus-compatible systems and other monitoring tools.

HTTP/2 server push

Proactively push resources to clients before they request it when HTTP/2 is used. (May be deprecated by browsers, but Caddy still has a valid implementation that is useful in certain applications.)

Rate limiting

Advanced, enterprise-grade rate limiter implemented using a ring buffer and sliding window algorithm that scales massively based on zone keys. Configure a cluster of Caddy instances with the same storage to distribute rate limiting across your fleet. No memory bound required like with other enterprise servers.
  • Local or distributed
  • Multiple zones
  • Buffer pooling
  • Only 1 goroutine
  • Configurable O(Kn) memory management
  • State persisted through reloads
  • Sets Retry-After header
  • Optional jitter
  • Highly programmable

Request body controls

Restrict the size of the request body by rejecting requests that are too large.

Reverse proxy

Caddy has a world-class reverse proxy, described in detail in a section below.

Rewrite requests

Make internal changes to requests before continuing to process them. This is useful to accept requests that need to be changed to conform to an expectation later on. Various aspects of the request can be changed such as method and URI.
  • Method
  • URI (path, query string)
  • Strip path prefix or suffix
  • Regular expression support
  • Intelligent URL-encoding and forward-slash handling

Static responses

Hard-code a static response into your config, with the ability to set the status code, header fields, and body. (This is often used to respond with HTTP redirects.) The connection may then be gracefully closed, or forcefully aborted if needed.

Subrouting

Group handlers into a "subroute" to treat several handlers as one, making certain logic easier to reason about.

Templates

Responses can be evaluated as templates, which give you the ability to turn proxied or static content into rich, dynamic content with variables, if statements, markdown rendering (with front matter support), and more.

Tracing

Support for distributed tracing using OpenTelemetry.

Variables

Read and write variables that can be used internally as you process requests.

WebDAV

Become a WebDAV server with one or two lines of config. Compatible with most WebDAV clients.

Reverse proxy

Caddy has the most flexible general-purpose reverse proxy in the world, featuring advanced request and response handling, dynamic routing, health checking, load balancing, circuit breaking, and more.

What makes Caddy's proxy unique is its design. Only the client-facing side of the proxy needs to be HTTP; the transport underlying the roundtrip with the backend can be fulfilled with any protocol!

Moreover, our proxy can be programmed with highly dynamic upstreams. That is, the available upstreams can change during in-flight requests! If no backends are available, Caddy can hold onto the request until one is.

High-level proxy features

Transports

Transports are how Caddy gets the response from the backend. Caddy's proxy can be a front for protocols other than HTTP by using alternate transport modules. This allows Caddy to generate HTTP responses from backends that don't even speak HTTP!
  • HTTP
  • FastCGI
  • NTLM

Load balancing

Selecting upstreams is a crucial function of any modern reverse proxy. Caddy has a variety of built-in load balancing policies to choose from to suit any production services. Some policies are extremely fast and lightweight; others provide upstream affinity based on properties of the client or request; others strive for even distribution by counting connections or using randomness and weights.
  • Random
  • Random Choose-N
  • Least connections
  • Round robin
  • Weighted round robin
  • First available
  • Remote IP hash
  • Client IP hash
  • URI hash
  • Query hash
  • Header hash
  • Cookie hash

Circuit breaking

A circuit breaker module can temporarily mark a backend as down before it actually goes down, to keep it up.
Latency-based

Health checking

Health checks detect when upstreams are unavailable. Passive health checks infer status from actual requests. Active health checks work in the background, out-of-band of client requests.
  • Active
  • Passive

Observability

The admin API exposes an endpoint to retrieve the traffic count and health status of the proxy upstreams.

Upstream sources

Caddy can get the list of upstreams in various ways. The most common is to write them into the configuration (static). Other ways are dynamic, by which a list of upstreams are returned for each request (these utilize configurable caching to enhance performance).
  • Static
  • Dynamic: A records
  • Dynamic: SRV records
  • Dynamic: Multiple sources combined

Retries

Requests can be retried until a backend is available to successfully handle the request. During this time, the list of upstreams may even be updated while the request is still pending!

Streaming

Responses can be streamed directly to the client, or for better wire performance, buffered slightly and flushed periodically.

Trusted proxies

In order to use proxy-related headers like X-Forwarded-For, you can specify a list of IP ranges of proxies you trust. By default Caddy doesn't trust the clients.

Header manipulation

Headers can be modified in the request going up to the backend and the response coming back down from the backend. This is similar to the general HTTP server's header handler, but this is applied while proxying.
  • Add
  • Set (overwrite)
  • Delete
  • Substring replace

Buffering

The proxy can optionally read the entire body before flushing it. This uses more memory but can be required by some backend applications or clients in some cases.
  • Requests
  • Responses

Request rewriting

Rewriting is a different concern from proxying and is normally handled separately, but sometimes you need to rewrite requests using information from the proxy like the chosen upstream. Caddy's proxy lets you do this.

Response interception

By default, Caddy's proxy simply writes responses to the client. However, you can intercept the upstream's response and handle it in other ways. This includes matching only certain responses and invoking a custom handler chain you specify.

Active health checks

Active health checks assume a backend is down by default until that is confirmed otherwise by a health check.

HTTP request parameters

Active health checks are performed against an HTTP endpoint on the upstream. You can customize the parameters for these HTTP requests to work for you.
  • Path & query string
  • Port
  • Headers

Timing

You can customize the interval at which active health checks are performed.

Success criteria

Each active health check can be customized with a set of criteria to determine healthy or unhealthy status.
  • Response timeout
  • HTTP status code
  • Regular expression match on body

Failure safety

Backends that are experiencing bugs and difficulties may sometimes respond with unexpectedly large response bodies. Caddy lets you limit this to preserve proxy resources.
Limit response size

Passive health checks

Passive health checks assume a backend is up by default until failure criteria are met in the course of proxying requests.

Failure criteria

All passive health checks count connection failures. In addition, you can set more criteria needed to deem a backend as healthy during a request.
  • Concurrent request limit exceeded
  • HTTP Status
  • Latency

Failure memory

You can customize how long to remember failures and how many failures need to be in memory to consider a backend to be down.

HTTP transport

This is the default transport module. It crafts a proxied HTTP request to obtain an HTTP response from the backend.

DNS resolvers

The system resolvers are used by default, but you can specify custom DNS resolvers per proxy handler.

TLS

Caddy can be configured to support TLS (formerly known as SSL) to the upstream.
  • Custom root CA pool
  • Client authentication to backend
  • Custom handshake timeout
  • Server Name Indicator (SNI)
  • Renegotiation level
  • Exempt certain ports from TLS

Connection pooling

Connections to backends are pooled for maximum efficiency and minimal latency.
  • HTTP Keep-Alive
  • Custom probe interval
  • Maximum idle connections (total and per-host)
  • Idle connection timeout

Compression

Caddy can compress requests for the roundtrip with the backend.
Gzip

Connection limit

You can limit the number of connections per host.

PROXY Protocol

The PROXY Protocol v1 and v2 are both supported when connecting to upstreams.

Timeouts

Various timeouts can be configured; some have sensible default values.
  • Connection (dial)
  • RFC 6555 fallback
  • Reading response headers
  • Expect continue
  • Read
  • Write

Custom buffer sizes

Tune the size of read/write buffers if you find that your application performs better with certain settings.
  • Read buffers
  • Write buffers

HTTP versions

Caddy's proxy supports multiple HTTP versions with the backend. By default, HTTP/1.1 and HTTP/2 are supported.
  • HTTP/1.1
  • HTTP/2
  • H2C (HTTP/2 over cleartext)

FastCGI transport

FastCGI is typically used to serve PHP applications via php-fpm. FastCGI responders may require additional information about the script being run such as script name, path relative to root, etc., and Caddy's FastCGI transport takes care of all of that and makes it configurable.

Highly efficient

Caddy's FastCGI client implementation has been optimized to rival the performance of memory-unsafe clients written in C, sometimes even surpassing their performance.

Path splitting

The path can be split, usually at the extension, to compute the proper PATH_INFO variable.

Resolve root symlink

Optionally require paths declared to symlinks to be updated if the symlink changes without php-fpm being restarted.

Environment variables

Read from the parent environment, and also set custom environment variables for your CGI script.

Timeouts

Set timeouts to conserve resources.
  • Dial (connect)
  • Read
  • Write

Capture stderr

Caddy can capture the output to stderr from the upstream and log them for visibility.

Static file server

Caddy's file server is the premier way of serving static files for your website.

It's simple: specify a root directory from which to serve the files, then each request path is automatically appended to the root to get the full path of the file to serve.

Kernel acceleration

Caddy bypasses user-space buffers whenever possible to speed up file downloads by a significant factor.
sendfile

Virtual file systems

By default, Caddy serves files from a directory you specify on the local disk, but this file access is pluggable and can be replaced by any virtualized file system modules. This allows you to serve static files from any file store such as databases, cloud storage, or even assets embedded directly in the web server binary!
  • Local disk
  • Embedded assets
  • Amazon AWS S3

Precompressed files

If your deployment pipeline compresses site resources, Caddy can automatically detect them and serve them in their "precompressed" encoding for higher efficiency and greater throughput.
  • Brotli
  • Zstandard
  • Gzip

Hide files and folders

Increase your security posture by proactively hiding potentially-sensitive files and folders that do or could exist in your site root. You can specify individual file/folder paths, filenames regardless of their path, or glob matches to hide files/folders with a particular pattern.
Exact paths, filenames, globular matching

Index filenames

Index files are files that are served if a directory is requested by the client. The filenames of index files to look for are customizable. Directory browsing can optionally be enabled if an index file is not found in a requested directory.
index.html, index.txt (customizable)

Conditional requests

Etag, Last-Modified, and related headers are supported.
  • Etag
  • Last-Modified
  • If-Match
  • If-None-Match
  • If-Modified-Since
  • If-Unmodified-Since
  • If-Range

Range requests

Common for streaming large files and resuming downloads, clients requesting certain ranges of files will not be disappointed or surprised. Caddy properly handles HTTP requests with Range headers.

Canonical paths

In general, there are multiple URIs for a single file or directory. For example: /, /index.html, and /index.html/ represent the same resource. Caddy uses HTTP redirects to enforce path canonicalization (removing trailing slashes from files, and adding them for directories).

Pass-thru mode

Sometimes you only want to serve a file if it exists, otherwise continue with the next handler in the chain, rather than returning an error to the client.

File browser

Caddy's file server comes alive through its modern file browser that looks attractive on mobile and desktop. It has more features and utility than any other standard HTTP file server!

Folder listings

Show the list of files in a folder when no index file (below) exists in that folder.
Exact paths, filenames, globular matching

Day and night themes

The color scheme automatically adjusts to match the system theme, whether it be light or dark, to avoid blinding you or being hard to read.
  • Light mode
  • Dark mode

Sort by columns

Quickly distill information about each directory and find items faster with sticky column sorting.
  • File/directory
  • Name
  • Size
  • Date modified

Filter

Every page load automatically focuses the cursor on a search box, so you can start typing a filename and filter large listings instantly.

Layout

Files can be shown in different layouts depending on how you want to view the listing. For example, the grid view is great for galleries.
  • List
  • Grid

Responsive design

The page width fluidly adjusts to accommodate screens of all sizes. Links are sufficiently sized to be easily tappable on touchscreens while still being information-dense enough to be useful.

JSON API

Requests with an Accept-Encoding: application/json header will be replied to with a JSON payload for programmatic or scripted access to your file listing.

Customizable listing template

If the default template isn't a good fit or you want to spice things up, customize the browse template to look and act any way you want!

File size visualization

File sizes are indicated by the length of the bar behind them, making it quick and easy to find outlier large and small files or to compare relative sizes at a glance.

File type icons

The file server recognizes dozens of common file types and shows associated icons to make identification easier when scanning the page.

Caddy is a living project with a TON of features. This page is not yet a comprehensive list of all the features and benefits provided by Caddy because there's so many to mention. We welcome contributions on GitHub!