WordPress Multisite on Azure App Service with AFD does not seem to support Domain Mapping

The packaged Azure WordPress AFD integration should not be used to force a single CUSTOM_DOMAIN when one multisite installation must distinguish several mapped domains; preserve each incoming host through Front Door and prevent the generated HTTP_HOST override from replacing it.

Recommended configuration

1. Keep the Front Door origin host header blank. Azure portal → Front Door profile → Origin groups → select the group → edit the App Service origin → clear Origin host header. With this field blank, Front Door forwards the incoming hostname—www.mysite.com or custom.mysite.com—as the Host header.^1^ This is required for WordPress Multisite to select a site by domain. Microsoft also recommends host preservation because replacing it can break routing, redirects, authentication, and cookies.^2^
2. Keep both hostnames registered in Front Door and App Service. For each hostname:
   • Front Door → Domains: add and validate the domain, then associate it with the route.
   • App Service → Settings → Custom domains: add and validate the same hostname.
   • Public DNS: direct site traffic to Front Door, not around it.
   App Service must recognize every preserved hostname so it can route the request to this web app.^1^ The App Service domain procedure includes adding the validation record and completing validation under Custom domains.^3^
3. Do not configure CUSTOM_DOMAIN as the canonical hostname for this multi-domain arrangement. The Azure image documents CUSTOM_DOMAIN as a single custom domain used by both AFD configuration and Multisite. Its documented AFD settings are:

      AFD_ENABLED=true
      AFD_ENDPOINT=<front-door-endpoint-hostname>
      CUSTOM_DOMAIN=<one-custom-domain>
   

   That model is suitable when the whole installation has one public hostname, but it cannot represent both www.mysite.com and custom.mysite.com simultaneously.^4^ The exact scenario—subdirectory Multisite behind Front Door with a second mapped domain—is still recorded as an open repository issue.^5^
4. Remove the generated static host override. The effective behavior must be equivalent to leaving the request host untouched:

      // Do not replace the incoming host with one canonical AFD domain.
      // WordPress Multisite must receive the host sent by the browser.
      //
      // Remove or disable:
      // $_SERVER['HTTP_HOST'] = getenv('AFD_DOMAIN');
   

   Your test confirms this is the discriminating change: once the override is absent, WordPress receives the preserved host and domain mapping works.

Should AFD_ENABLED be set to false?

Setting AFD_ENABLED=false is a workable way to stop the Azure image from regenerating its single-domain AFD configuration only if you take ownership of the Front Door and WordPress proxy configuration. It is not the repository’s documented normal configuration: the image documentation says AFD_ENABLED and AFD_ENDPOINT should be preserved for proper operation.^4^

Therefore:

• Do not regard AFD_ENABLED=false plus a manual edit as a generally supported multisite parameter combination.
• In the current image, it is a practical workaround for the image’s single-canonical-host behavior.
• Because generated files can change during image updates, use a controlled custom image or an idempotent startup customization rather than relying on a one-time manual edit.
• Test image upgrades in a deployment slot before production.

Why the condition ran without an App Service AFD_DOMAIN setting

The absence of AFD_DOMAIN in App Service → Configuration does not prove that it is absent inside the running container. The Azure image’s Front Door startup configuration derives runtime WordPress settings from AFD_ENABLED, AFD_ENDPOINT, and CUSTOM_DOMAIN; environment values can therefore be created during container initialization rather than appearing as user-defined App Service settings.^4^

Check the live container before and after changing AFD_ENABLED:

printenv | grep -E '^(AFD_|CUSTOM_DOMAIN|WEBSITE_HOSTNAME)='
php -r 'var_dump(getenv("AFD_DOMAIN"));'
grep -n -A4 -B2 "overriding HTTP_HOST" /home/site/wwwroot/wp-config.php

If AFD_DOMAIN has a value at runtime, the override makes every request look as though it used that one hostname. Both domains consequently resolve to the same network site, which matches the observed result.

References

1. Origins and origin groups in Azure Front Door (front-door-standard-premium)
2. Preserve the original HTTP host name between a reverse proxy and its back-end web application
3. Set up an existing custom domain in Azure App Service
4. wordpress-linux-appservice/WordPress/wordpress_afd ... - GitHub
5. #210 Utilizing MultiSite with Azure Front Door and Multiple Subdomains