被接受的答案提到了客户将他们的DNS指向您的Web服务器。但是,在当今这个时代,这还不足以使其正常工作。
如果您的客户只是将CNAME指向您的域或创建指向您的IP的A记录,并且您不处理这些自定义域的TLS终止,则您的应用程序将不支持HTTPS,没有它,您的应用程序将无法在这些自定义域上的现代浏览器中工作。
您需要在Web服务器前设置一个TLS终止反向代理。此代理可以在单独的机器上运行,但您也可以在与Web服务器相同的机器上运行它。
CNAME vs A记录
如果您的客户想要在其子域上使用您的应用程序,例如app.customer.com
,则他们可以创建指向您的代理的CNAME app.customer.com
。
如果他们想要在其根域上使用您的应用程序,例如customer.com
,那么他们将不得不在customer.com
上创建指向您的代理IP的A记录。确保此IP永远不会更改!
如何处理TLS终止?
为了使TLS终止工作,您需要为这些自定义域发出TLS证书。您可以使用Let's Encrypt来完成。您的代理将看到传入请求的“Host”标头,例如“app.customer1.com”或“customer2.com”等,然后它将通过检查SNI来决定使用哪个TLS证书。
代理可以设置为自动为这些自定义域发出和更新证书。在新自定义域的第一个请求中,代理将看到它没有适当的证书。它将向Let's Encrypt请求新证书。Let's Encrypt将首先发出挑战以查看您是否管理该域,并且由于客户已经创建了指向您的代理的CNAME或A记录,这告诉Let's Encrypt您确实管理该域,并允许您为其发出证书。
为了自动发出和更新证书,我建议使用Caddyserver、greenlock.js、OpenResty(Nginx)。
简而言之,这里发生了什么;
Caddyserver在443和80上监听,它接收请求,自动发出和更新证书,将流量代理到您的后端。
如何在我的后端处理它
您的代理正在终止TLS并将请求代理到后端。但是,您的后端不知道请求背后的原始客户是谁。这就是为什么您需要告诉代理在代理请求时包含其他标头以识别客户的原因。只需添加X-Serve-For: app.customer.com
或X-Serve-For: customer2.com
或原始请求的Host
标头。
现在,在后端接收代理请求时,您可以读取此自定义标头,并知道请求背后的客户是谁。您可以根据此实现逻辑,显示属于该客户的数据等。
更多信息
在代理池前面放置负载均衡器以提高可用性。您还必须使用分布式存储来存储证书和Let's Encrypt挑战。使用AWS ECS或EBS进行自动恢复,如果出现故障,否则,您可能会在半夜被唤醒,重新启动机器或手动重启代理。
如果您需要更多详细信息,可以在Twitter上私信我@dragocrnjac
<a href="{{ domain_url('foo') }}">
而不是<a href="http://foo">
。 - Amberdns_get_record()
可能对您有用。 - animuson./custom-name
文件夹以及进行A记录检查(后端nslookup)。 - Lawrence Cherone