Scale up as you grow — whether you're running one virtual machine or ten thousand.

From GPU-powered inference and Kubernetes to managed databases and storage, get everything you need to build, scale, and deploy intelligent applications.

I just wanted to share the answer to an issue that has been giving me headaches for a couple of days.
I needed to have this setup:
I configured Shell-in-a-box in the server, configured the DNS entry for ssh.example.com and also configured the server block for Nginx with the following setup:
server {
server_name ssh.example.com;
location / {
proxy_pass http://localhost:4200;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_read_timeout 350;
proxy_connect_timeout 350;
}
location ~ /\.ht {
deny all;
}
#
# HERE GOES ALL THE Let´s Encrypt auto configuration stuff.
#
}
After that setup, I always got an 502 - Bad Gateway error. no matter what I did, additionally /var/log/nginx/error.log showed this every time I opened ssh.example.com
[error] 15177#15177: *6040 upstream prematurely closed connection while reading response header from upstream, client: 208.87.234.202, server: ssh.example.com
Finally understanding the log, what “upstream prematurely closed connection” means is that, nginx got the request, knows where to send it, it then sends it but the receiving application (Shell-in-a-box), closed the connection forcefully and prematurely. Hence, the problem lies in the application itself, right?
After a couple of days reading, I found the answer. Shell-in-a-box only receives requests in https protocol, but in the other hand, all examples of reverse proxy explicitly specify that http should be used to proxy the requests to the application.
So after changing proxy_pass http://localhost:4200; to proxy_pass https://localhost:4200; al worked beautifully.
Edward Sitarski
1fd6b9d2a2b94ee4b3e8ee6d5e2587
Traceurity
fadecomic
Mollie Semmes
Will Walters
f4df2e98b9c74f7eb7f6a0629cf1c4
erel
fingers
fingers