I'm literally only using it to proxy my IP since I host my instance out of my house. Now, I read that I shouldn't even care about this, since it is my 'public' ip after all. But I wouldn't mind people not knowing my general geolocation either.
Is reverse proxying through a cloud VPS a viable alternative? I'm willing to fork over some shekels/month to give myself a lil bit more privacy.
@thegreatape your instance is sending messages to other servers from your home public ip not cloudflare so you already have no privacy. if you set up a VPS you can configure it so that both incoming and outgoing traffic are from the VPS and you are actually private.
@thegreatape I can give you some hints even if i won't do the actual work. You can set up an nginx server on a VPS, then in the server config you reverse proxy it to your home IP. Then, for outgoing messages, you configure a socks5 proxy on your VPS, you open your firewall to only your home IP address for it, then you configure Pleroma to use it:
@Moon KING SHIT. Yeah I'm definitely not a network expert by any means, I can only imagine there's a LOT I'm not doing that makes using CF pointless anyways 😂
@matty@thegreatape you mean forward proxying? you can do what we do and use wireguard, http or socks5 (using something like tinyproxy) and set up http proxy in pleroma for forward proxying
@thegreatape you can just move your nginx config to a VPS and point the phoenix proxy_pass to your home IP providing its static
with that VPS you can also use IPtables (or nginx reverse proxy) to forward traffic to any other port, too. so if you wanted to host a minecraft server at home and hide it, you can do that too.
@matty@graf@thegreatape You need a way to route traffic from pleroma to your public proxy server and nginx won't handle that for you. wireguard is actually very easy to use and built into the kernel. You just need to install wg-quick to configure it. Also very light weight.
@matty@thegreatape you would have to setup a wireguard server on the VPS you have nginx on and connect the pleroma instance to that via wireguard but yea you can do that
@matty@thegreatape nginx only does reverse proxy aka incoming connections. you are asking for intercommunication which is forward (outgoing) proxying which you need VPN (like wireguard or openvpn), http or socks5 proxy to achieve
Ah I see. In that case you could use the same server as both the reverse proxy and forward proxy, correct? You'd just have to set up the forward proxy on the reverse proxy server
@matty@thegreatape not really. you can, for example spawn a digitalocean droplet (dont do this) and run this script and have wireguard installed and config’d in less than 5 minutes. install nginx and copy your pleroma nginx config to that VPS, change proxy_pass to your actual IP and get an SSL cert and you’re done. 15 minutes maybe
@matty@graf@thegreatape it's built into the kernel on your nginx reverse proxy. Nothing but the CLI tools to install. It's like any other VPN as far as possible uses.
@matty@thatguyoverthere@thegreatape i linked you to the script that installs wireguard. it’s self hosted. but a lot of VPN providers offer it, like torguard (code jannyduty for 50% off for life)
@thatguyoverthere@matty@graf@thegreatape can confirm that setting up Wireguard is easier and safer than setting up a socks5 server like Dante. I suggested socks5 proxy for a couple reasons but mainly inertia, I'm just used to doing that way.
@matty@thatguyoverthere@thegreatape if you want to 'pull' extra load off pleroma, stop forwarding everything to @Phoenix and set up dedicated nginx location blocks for your media and emojis. there's no reason you need to have phoenix process your emojis every time someone opens it. this allows you to cache them and also speed up delivery. start with that before you add more shit into the mix
remove media from that, copy it and set the location as location ~ ^/media { and location ~ ^/emoji { then replace proxy_pass with try_files $uri @phoenix;
@matty@Phoenix@thatguyoverthere@thegreatape if I were you I'd be commenting everything out rather than removing them but no. these are supplemental. ^/emoji, ^/media and ^/proxy are all their location blocks at the end of our config (before our rate limit directive on the api)
we have them configured individually because each requires different shit. media caching is permanent vs emoji which may not be, for example