docs: Minor tweaks, clarifications.

src/docs/markdown/architecture.md

@@ -135,7 +135,7 @@ You can [watch a video about the design of Caddy 2 here](https://www.youtube.com
 
 A config reload works by provisioning the new modules, and if all succeed, the old ones are cleaned up. For a brief period, two configs are operational at the same time.
 
-Each configuration is associated with a [context](https://pkg.go.dev/github.com/caddyserver/caddy/v2?tab=doc#Context) which holds all the module state, so most state escapes the scope of a config. This is good news for correctness, performance, and simplicity!
+Each configuration is associated with a [context](https://pkg.go.dev/github.com/caddyserver/caddy/v2?tab=doc#Context) which holds all the module state, so most state never escapes the scope of a config. This is good news for correctness, performance, and simplicity!
 
 However, sometimes truly global state is necessary. For example, the reverse proxy may keep track of the health of its upstreams; since there is only one of each upstream globally, it would be bad if it forgot about them every time a minor config change was made. Fortunately, Caddy [provides facilities](https://pkg.go.dev/github.com/caddyserver/caddy/v2?tab=doc#UsagePool) similar to a language runtime's garbage collector to keep global state tidy.
 

src/docs/markdown/caddyfile/concepts.md

@@ -154,6 +154,8 @@ These are examples of valid addresses:
 - `127.0.0.1`
 - `[::1]:2015`
 - `example.com/foo/*`
+- `*.example.com`
+- `http://`
 
 <aside class="tip">
 	<a href="/docs/automatic-https">Automatic HTTPS</a> is enabled if your site's address contains a hostname or IP address. This behavior is purely implicit, however, so it never overrides any explicit configuration. For example, if the site's address is <code>http://example.com</code>, auto-HTTPS will not activate because the scheme is explicitly <code>http://</code>.
@@ -163,6 +165,8 @@ From the address, Caddy can potentially infer the scheme, host, port, and path o
 
 If you specify a hostname, only requests with a matching Host header will be honored. In other words, if the site address is `localhost`, then Caddy will not match requests to `127.0.0.1`.
 
+Wildcards (`*`) may be used, but only to represent precisely one label of the hostname. For example, `*.example.com` matches `foo.example.com` but not `foo.bar.example.com`, and `*` matches `localhost` but not `example.com`. To catch all hosts, omit the host portion of the address.
+
 If multiple sites share the same definition, you can list all of them together:
 
 ```

src/docs/markdown/caddyfile/directives/reverse_proxy.md

@@ -52,7 +52,7 @@ reverse_proxy [<matcher>] [<upstreams...>] {
 - **&lt;upstreams...&gt;** is a list of upstreams (backends) to which to proxy.
 - **to** is an alternate way to specify the list of upstreams, one (or more) per line.
 
-Upstream addresses can take the form of a conventional [Caddy network address](/docs/conventions#network-addresses) or a URL that contains only scheme and host/port. Valid examples:
+Upstream addresses can take the form of a conventional [Caddy network address](/docs/conventions#network-addresses) or a URL that contains only scheme and host/port, with a special exception that the scheme may be prefixed by `srv+` to enable SRV DNS record lookups for load balancing. Valid examples:
 
 - `localhost:4000`
 - `127.0.0.1:4000`
@@ -60,6 +60,7 @@ Upstream addresses can take the form of a conventional [Caddy network address](/
 - `https://example.com`
 - `example.com`
 - `unix//var/php.sock`
+- `srv+http://internal:5099`
 
 Note: Schemes cannot be mixed, since they modify the common transport configuration (a TLS-enabled transport cannot carry both HTTPS and plaintext HTTP). Specifying ports 80 and 443 are the same as specifying the HTTP and HTTPS schemes, respectively. Any explicit transport configuration will not be overwritten, and omitting schemes or using other ports will not assume a particular transport. Additionally, schemes cannot contain paths or query strings, as that would imply simultaneous rewriting the request while proxying, which behavior is not defined or supported.
 

src/docs/markdown/config-adapters.md

@@ -17,6 +17,7 @@ The following config adapters are currently available (some are third-party proj
 - [**jsonc**](https://github.com/caddyserver/jsonc-adapter)
 - [**json5**](https://github.com/caddyserver/json5-adapter)
 - [**yaml**](https://github.com/iamd3vil/caddy_yaml_adapter)
+- [**cue**](https://github.com/caddyserver/cue-adapter)
 
 (This list is the temporary home for known adapters until our new website is finished.)