@scottalanmiller said in Mattermost Behind Nginx and Cloudflare Script Load Error: @Pete-S said in Mattermost Behind Nginx and Cloudflare Script Load Error: @scottalanmiller said in Mattermost Behind Nginx and Cloudflare Script Load Error: @black3dynamite said in Mattermost Behind Nginx and Cloudflare Script Load Error: s your setup is Cloudflare proxy -> Nginx proxy -> apache (mattermost)? CF Proxy > Nginx Proxy > Mattermost (MM is its own server) And yes, if I disable the CF Proxy, it works. Why the double reverse proxies? That's the standard. You are always expected to have your node.js servers behind a reverse proxy. And CloudFlare is the CDN cache in front. This is the universal standard for all web servers. Plenty of times to avoid it, of course, but this is the baseline system design. In this case, MM is a raw node server so has none of the protections or handling of a system like Nginx. Nginx also provides the ability to have multiple sites behind one IP address. MM doesn't do that on its own, nor does CloudFlare. No different than how MangoLassi is on NodeBB, also a node platform, behind Nginx, behind CloudFlare. CF can't do the details port and IP handling, Nginx can't do the globally distributed cache. Thanks for the clarification Scott. I (wrongly) thought that Cloudflare was a full featured proxy and could do the same job as haproxy, nginx etc.

You have the answer in the logs you posted. Nginx can't connect to php handler daemon on port 9000, most likely php-fpm.

Got it all working. Thanks for everyone's assistance!

@wrx7m said in Configure Nginx as Reverse Proxy for ScreenConnect to Enable Lets Encrypt: Less to that than I thought there would be. It's surprisingly simple and basic. It's really just passing one port to another, and using SSL. About the most basic setup you can have.

@IRJ said in Massive speed increase when switching WordPress from apache to nginx: I really wanted to do everything server side and be as lean as possible. I wanted zero plugins related to performance on my WP site. Lean WP, that's an oxymoron if anything I've heard before that some sites are slower with cloudflare CDN compared to going straight to the site. Are you using http/2 as well? Most likely in this case, the switch to nginx from apache itself didn't make anything noticeably faster but the caching and compression did.

dhcp

If you get external DNS to go to the nginx proxy you could probably allow all traffic to the URL path that lets encrypt needs and then create a whitelist for everything else.

Well let's talk about fedora and updating killing a laptop lol....

Worth noting that the issue comes back when you upgrade to Fedora 31 as well. Same fix still applies.

@black3dynamite said in NGINX Reverse Proxy Help - Error code: SSL_ERROR_RX_RECORD_TOO_LONG: In the server block, add ssl_protocols TLSv1.2; and reload nginx no joy. Incognito mode did not work either.

I'd normally keep swap space too but I know for sure you can run without it successfully because we used to do that with embedded linux for years - with devices that had years of uptime. With memory ballooning you can overcommit RAM and the hypervisor can swap guest RAM to disk if it comes to that. I don't know which hypervisors supports it though. As always it depends on how much you want to cram out of your gear.

@scottalanmiller said in NGINX vs Apache: @wrx7m said in NGINX vs Apache: Does Apache have a paid version? I know that nginx reverse proxy is free, but the web server (at least used to be) a paid product. Apache is totally free. Nginx is free for all normal purposes, it is advanced features that I've never even thought of wanting that are paid. Ahh. Ok. I misconstrued those features as being the entire product.

@Donahue said in Nginx questions: looks like the NC thing might be a bug with just iOS and using a reverse proxy https://github.com/nextcloud/server/issues/11464 yep, the "old method" indeed did work.

@scottalanmiller said in NGinx Configuration Block for Zimbra Reverse Proxy: Someone was looking for this specifically so... server { client_max_body_size 80M; server_name my.domain.com; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_set_header X-NginX-Proxy true; proxy_redirect off; location / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_set_header X-NginX-Proxy true; proxy_pass https://myip:443/; proxy_redirect off; # Socket.IO Support proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } listen 80; ssl_stapling on; ssl_stapling_verify on; ssl_session_cache shared:SSL:10m; add_header Strict-Transport-Security "max-age=31536000; includeSubdomains"; listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/my.domain.com/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/my.domain.com/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot } Remember to create one for the Admin console on port 7071.

@wirestyle22 said in Nextcloud Update 14.04 Security Warning: Strict-Transport-Security If you are using Nginx Reverse Proxy, adding add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"; in your server block should remove that warning.

Sorry, ignore me. I got this figured out. I was being really dumb and had the wrong config.json file open and didn't know what I was looking at. Just ignore. Yes, the socket.io settings were missing, but were on my screen so I was sure that they were there.

@Romo said in Collabora CODE and NextCloud Integration Shows Blank Editing Page and Spinning Circle: Just got it working, it was indeed a DNS issue. When launching the docker container I added the --add-host name:ip option to add an entry to the hosts file that pointed to the internal ip of our nextcloud server and that made it properly work. Its now properly working I'll have to try that tonight!

@phqzgunsfjror said in Anyone using Jitsi behind Nginx: @JaredBusch Thank you for sharing the configuration how you put the Nginx in front of Jitsi. I tried exactly the same way and for some reason it isn't working for me. The original post is a little old. Hence, let me ask you whether it still works for you. And let me know whether you added something in the configuration for a newer Jitsi version. Actually I have the same behavior like described on reddit (502 Bad Gateway) : https://www.reddit.com/r/selfhosted/comments/fve1ib/jitsi_with_nginx_proxy/ The difference is I dont use docker but the normal installation on ubuntu (https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md). Regarding ports I did: myrouter (80, 443) -> VM1: nginx (with your config) myrouter (10000 udp) -> VM2: jitsi It seems the jitsi team moved the documentation to somewhere else a couple of days ago ... including some more information about nginx reverse proxy. https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-quickstart If the installation is behind a proxying nginx server, remove /etc/nginx/modules-enabled/60-jitsi-meet.conf. Then go to /etc/nginx/site-available/your-conf and change it to listen on 443 instead of 4444 and restart nginx. I did that on my jitsi vm and now it works like a charm. The nginx reverse proxy config above is still enough for the current jitsi version. From my end there was nothing to do with the stuff about NAT (the restart of the jitsi vm was enough). I hope it helps someone else. The nginx reverse proxy gives me the opportunity using multiple applications behind ports 80/443 at home.

All the Z-Push state files are located on /var/lib/z-push. I deleted them all for an user and then boom everything started working.

Nice Guide! I did this all and automated it for LXQ

Probably pretty minor, but just patch nGinx anyway

nano /var/www/bookstack/.env contains a commented line for APP_URL=http://bookstack.dev. Uncommenting it and changing it to APP_URL=https://wiki.domain.com fixed the issue for me.

@wirestyle22 said in Renewing Let's Encrypt certificates using a systemd timer: sudo systemctl enable certbot-renewal.timer As I did this again today, I thought I would post my quick tweak to this because I do not like the idea of it running hourly. I set mine to run twice a day with a 1 hour randomizer. [Timer] OnCalendar=*-*-* 01,13:00:00 RandomizedDelaySec=3600 Unit=certbot-renewal.service

@taurex said in Cloudflare and Nginx reverse proxy background.: @travisdh1 Are there any benefits of configuring your own reverse-proxy if it's running behind CloudFlare that is essentially the one already? I know they offer their own Origin CA certs that you can install on your web servers to encrypt the traffic between CF and your cloud. As long as you're happy to stick with CloudFlare, there will be no need to run cron jobs with certbot renewals every 3 months. As @JaredBusch said, you can run self-signed certs with CloudFlare just fine. This was for my home lab, so I purposely do things the hard way sometimes, just to see what it's like. That's why I originally tackled this anyway. Running a reverse proxy mostly so I don't have to pay for nearly 30 IP addresses on the box I rent for it.

@jaredbusch Hm. I'm getting too many rewrite errors now. Some odd problems occurring. Relative pathing problem?

@stacksofplates said in Looking to migrate Nginx and LetsEncrypt: @jaredbusch said in Looking to migrate Nginx and LetsEncrypt: @stacksofplates said in Looking to migrate Nginx and LetsEncrypt: If you start over with a new system so you still get notifications of old certs expiring? Aren't these handled at the domain level so it knows that a new system has a newer cert? Honestly asking since I haven't run into this yet. No. It is handled on the cert serial number level. Ah ok. I've moved things in the past by simply reissuing on the new server, and dealing with the expiring certs is an annoyance.

@scottalanmiller said in Anyone Using Collabora and NextCloud Behind NGinx?: Not sure how I should have things configured. I believe that I followed all of the instructions properly, but it is not working and there are no really clear instructions for a dual server scenario. All of the official stuff lists single server and Apache. The one thing I remember having issues with was that it wants to communicate over the same "channel" in between the Collabora and NextCloud servers, so if the external browser connection is https, then it's not happy and throws errors if the back end isn't communicating over https as well. Getting that https channel setup with the recommended Drupal container and instructions for that didn't seem to work, and was such a pain I gave up trying to get it fixed at the time.