# كيفية إعداد Discourse خلف وكيل AWS أو Google Cloud مع SSL

**URL:** https://meta.discourse.org/t/how-do-i-configure-discourse-behind-an-aws-or-google-cloud-proxy-with-ssl/78943
**Category:** Self-hosting
**Created:** [24 يناير 2018، 11:11ص UTC](https://meta.discourse.org/t/how-do-i-configure-discourse-behind-an-aws-or-google-cloud-proxy-with-ssl/78943 "2018-01-24T11:11:31Z")
**Posts on this page:** 2
**Page:** 2

<div class="post-metadata">

### Author: ![mc0e](https://avatars.discourse-cdn.com/v4/letter/m/c77e96/32.png) [@mc0e](https://meta.discourse.org/u/mc0e)
#### Post date: [25 مارس 2019، 7:16ص UTC](https://meta.discourse.org/t/how-do-i-configure-discourse-behind-an-aws-or-google-cloud-proxy-with-ssl/78943/26 "2019-03-25T07:16:55Z")

</div>

I thought you were on the mark when you identified the need for discourse to be aware of http\_x\_forwarded\_proto, but why do we need a redirection rule here?

If SSL termination is done by an external proxy which forwards requests to discourse over HTTP, then discourse still may need to know that it can accept submissions as secure, and that it can and should produce https URLs in pages.

If Discourse doesn’t have this capability, then I imagine the best alternative is to have the proxy use HTTPS to talk to discourse, though it’s wasteful of CPU, and may add to certificate management. I’ve yet to look into what happens with conflicting LetsEncrypt configurations between the proxy and the back end, but suspect it might be a source of trouble.

---

<div class="post-metadata">

### Author: ![system](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/system/32/443519_2.png) [@system](https://meta.discourse.org/u/system)
#### Post date: [20 مايو 2022، 6:23ص UTC](https://meta.discourse.org/t/how-do-i-configure-discourse-behind-an-aws-or-google-cloud-proxy-with-ssl/78943/27 "2022-05-20T06:23:41Z")

</div>



[Previous page](https://meta.discourse.org/t/how-do-i-configure-discourse-behind-an-aws-or-google-cloud-proxy-with-ssl/78943.md?page=1)