@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.

0_1543340489749_collabora-2.png

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.

@aboka said in Setup LetsEncrypt Certbot with CLoudFlare DNS authentication (Ubuntu):

hi, thanks for sharing this guide, would like to ask, what port does ppa:certbot use? im running nginx and its already using 80 & 443. i need to find a way to renew the cert when using Cloudflare as the common way(certbot renew) will not work. thank you.

There are certbot options to use the running server (Nginx in this case.) But I agree with Jared, better to use DNS.

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

027a0074-88ec-4c1f-b114-91722521529b-image.png

@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.

@jaredbusch said in 302 Moved Error:

That auto generated stuff is only sending stuff to the Apache host on the same box as Nginx.

Thanks for your valuable comments.

I solved this problem.
I've erased all routing on Nginx/Apache :smiling_face_with_smiling_eyes: ,

I created a virtual server for HAproxy, I installed HAproxy and currently all virtual servers routing process was completed.

Only I have one problem with HAproxy conf. file, I do not know how to do FTP Routing.
if you want to see the topic, please visit this topic.

@jaredbusch said in Rewriting A Single Resource URL On A Webpage:

@nashbrydges said in Rewriting A Single Resource URL On A Webpage:

@jaredbusch said in Rewriting A Single Resource URL On A Webpage:

@nashbrydges said in Rewriting A Single Resource URL On A Webpage:

Currently (which breaks proper tracking because the script is blocked by most browsers):
<script src="http://sub.domain.com/mtc.js" async data-source="mautic"></script>

A location should handle this.

in your :80 server block add a location

location /mtc.jc { rewrtie ^ https://sub.domain.com/mtc.js; }

Thanks, I'll give that a try.

Pulled that right out of my ass, it very well may not work. But you get the general idea.

It does work, as I have used it on Apache like my post below:
https://mangolassi.it/topic/16660/reverse-or-forward-proxy-setup/3

@black3dynamite said in Wordpress Install - Page is trying to load unsafe script:

@NashBrydges
Change
CustomLog /var/log/access.log combined
to
CustomLog /var/log/httpd/access.log combined

Good catch. Thanks.

I was able to fix the issue with the following lines on Apache as Reverse Proxy

ProxyPass /soap/v1/ https://api.authorize.net/soap/v1/ ProxyPassReverse /soap/v1/ https://api.authorize.net/soap/v1/

I assume this can also be done on Ngnix as well. So I will find out.