As per RFC 5246 (section 7.4.2):
This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.
So the server certificate would have to come first, then the certificate of the intermediate CA signing server certificate, then the certificate of the intermediate CA signing the certificate of the first CA and so on. Basically, the certificate chain in reverse order, starting with the server certificate.
However, with TLS 1.3 this requirement seems to have been removed, since RFC 8446 (the successor of RFC 5246) now says in section 4.4.2
certificate_list: A sequence (chain) of CertificateEntry structures, each containing a single certificate and set of extensions.
Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it; however, some implementations allowed some flexibility. Servers sometimes send both a current and deprecated intermediate for transitional purposes, and others are simply configured incorrectly, but these cases can nonetheless be validated properly. For maximum compatibility, all implementations SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings from any TLS version, with the exception of the end-entity certificate which MUST be first.
So the order would not matter anymore except for the actual server certificate, which would still have to be the first certificate in the chain file. Still, for the time being I'd recommend sticking with the traditional order to avoid problems until your web server has implemented this change.