Incoming requests for a domain are first processed by the load balancer, which directs the requests to the proper infrastructure. After the infrastructure receives the request, Apache handles routing the requests to the proper website by matching the requests to the configured site root directory. Unexpected behavior can result when wildcard domains (*.example.com) are used.

Due to the way Apache processes domain matching, traffic might be routed to the environment with the wildcard domain, instead of the explicitly-named domain you intended.

Unlike Nginx on the load balancer, Apache processes domain names alphanumerically, in the order they appear in the configuration files, instead of respecting more specific domains before wildcard domains. This ordering can lead to a wildcard domain configured for one environment catching traffic you intended to route to a different environment.

Incoming requests for a domain are first processed by the load balancer, which directs the requests to the proper infrastructure. After the infrastructure receives the request, Apache handles routing the requests to the proper website by matching the requests to the configured site root directory. Unexpected behavior can result when wildcard domains (*.example.com) are used.

Due to the way Apache processes domain matching, traffic might be routed to the environment with the wildcard domain, instead of the explicitly-named domain you intended.

Unlike Nginx on the load balancer, Apache processes domain names alphanumerically, in the order they appear in the configuration files, instead of respecting more specific domains before wildcard domains. This ordering can lead to a wildcard domain configured for one environment catching traffic you intended to route to a different environment.

For example, let’s say we have a customer using the sitename delightful on Cloud Platform Professional. Since Cloud Platform Professional appends random alphanumeric strings to sitenames, the resulting configuration files would appear like this:

delightful978inmswak-152457.conf
delightful82upsouk-168414.conf
delightfulmlhjfbjppg-154567.conf

These configuration files correspond to the following environments on this infrastructure:

• Dev = delightful978inmswak-152457.conf
• Prod = delightful82upsouk-168414.conf
• Test/Staging = delightfulmlhjfbjppg-154567.conf

Inside each of these configuration files are a set of variables called ServerAlias. These variables are the domain names displayed on your Domains page. The configuration files mentioned above contain the following ServerAlias definitions:

delightful978inmswak-152457.conf
    ServerAlias dev.delightful.com
    ServerAlias loadtest.delightful978inmswak.devcloud.acquia-sites.com

delightful82upsouk-168414.conf
    ServerAlias *.delightful.com delightful.com www.delightful.com
    ServerAlias dc-278394-136583925.us-east-1.elb.amazonaws.com
    ServerAlias loadtest.delightful82upsouk.devcloud.acquia-sites.com

delightfulmlhjfbjppg-154567.conf
    ServerAlias test.delightful.com
    ServerAlias loadtest.delightfulmlhjfbjppg.devcloud.acquia-sites.com

If a request is received for test.delightful.com, the request would be caught by the *.delightful.com rule, which Apache reads before the ServerAlias for test.delightful.com. The content for test.delightful.com would appear on the production environment, instead of non-production environment.

It is not possible to circumvent the method Apache handles wildcard behavior in the domain matching process. If you determine that your subscription is serving the wrong version of your website, and you use wildcard domains, try removing the wildcard to attempt to resolve the issue.