Dispatcher configuration deployment fails due to missing ServerAlias or X-Vhost configuration

Dispatcher configuration deployments in Cloud Manager fail at the Code Scanning or TestCacheInvalidation phase even when local validation reports no issues. The failures happen when no enabled vhost matches the hostnames Cloud Manager uses for its internal tests, or when the matching vhost doesn’t set an X-Vhost header, so the requests fall into the catch-all vhost. Missing default.vhost symlinks, absent ServerAlias values, and rewrite rules that block invalidate.cache produce the same result. Ensuring at least one enabled vhost handles 127.0.0.1, localhost, *.local, and the cloud domains and sets an X-Vhost header resolves the failure.

Description description

Issue: Dispatcher deployment fails at Code Scanning or TestCacheInvalidation with an X-Vhost catch-all error

Description

Cloud Manager dispatcher pipelines fail at Code Scanning or TestCacheInvalidation despite the dispatcher validator reporting No issues found. Logs show the validator succeeding, followed by a failure such as Expected header X-Vhost to be existing and not: catch-all, got: catch-all or invalidation returning HTTP 403. This happens when no enabled vhost matches the dispatcher invalidation hostnames or doesn’t set an X-Vhost header, leaving Cloud Manager tests to fall into the catch-all vhost. Additional failures occur when the default.vhost symlink is missing, required ServerAlias values are absent, or redirect/rewrite rules block invalidate.cache.

Environment:

Issue/Symptoms:

Root cause:

Cloud Manager performs internal Dispatcher tests that require at least one enabled vhost to match requests coming from 127.0.0.1, localhost, *.local, *.adobeaemcloud.com, and *.adobeaemcloud.net. These tests must also return an X-Vhost header. When these hostnames aren’t matched by any enabled vhost, or the matched vhost doesn’t set X-Vhost, Cloud Manager treats the response as catch-all, causing TestCacheInvalidation and other tests to fail. The same failure occurs when the default.vhost symlink is missing, custom rewrite rules block invalidation, or artifacts are missing during copy steps.

How to confirm

Resolution resolution

A glob * alone isn’t guaranteed to work. If the aliases are missing, add them and redeploy.
2. Confirm the vhost is enabled. Check conf.d/enabled_vhosts/ for a symlink pointing to a vhost with the required ServerAlias entries. For example: default.vhost -> ../available_vhosts/default.vhost. If the symlink is missing, add it and push the commit.
3. Set the X-Vhost header. In the matching vhost, add:

Header add X-Vhost "publish"

Test requests then return an X-Vhost value other than catch-all. Confirm no rewrite rule strips response headers.
4. Check for rewrite rules that block invalidate.cache. Search for rules that reject the Cloud Manager test client. For example: a rule matching the Go-http-client user agent that returns a 403:

RewriteCond %{HTTP_USER_AGENT} Go-http-client.*$
RewriteRule .* - [ R=403,L]

Remove or bypass the offending rule so invalidation returns HTTP 200. If needed, temporarily disable suspect rewrites and redeploy.
5. Validate the configuration locally:

./bin/validate.sh dispatcher/src

Confirm the output shows No issues found and Syntax OK. Fix any local syntax errors before redeploying.
6. Commit the changes and rerun the dispatcher pipeline. Confirm Code Scanning and TestCacheInvalidation pass.

Validation

Related reading