Commit dfae0050 authored by rinpatch's avatar rinpatch

Move out of Gitlab Wiki

I understand that this change is quite unreadable and hard to review, sorry for forgetting to do atomic commits. This patch does not change too much content wise, it just
* Gets everything from gitlab wiki
* Removes some specific gitlab hacks
* Formats all documentation file names to be in snake case so they look the same way as our code does
parent 926bf114
Pipeline #9593 passed with stages
in 7 minutes and 46 seconds
......@@ -28,7 +28,7 @@ While we don’t provide docker files, other people have written very good ones.
* Run `mix deps.get` to install elixir dependencies.
* Run `mix pleroma.instance gen`. This will ask you questions about your instance and generate a configuration file in `config/generated_config.exs`. Check that and copy it to either `config/dev.secret.exs` or `config/prod.secret.exs`. It will also create a `config/setup_db.psql`, which you should run as the PostgreSQL superuser (i.e., `sudo -u postgres psql -f config/setup_db.psql`). It will create the database, user, and password you gave `mix pleroma.gen.instance` earlier, as well as set up the necessary extensions in the database. PostgreSQL superuser privileges are only needed for this step.
* For these next steps, the default will be to run pleroma using the dev configuration file, `config/dev.secret.exs`. To run them using the prod config file, prefix each command at the shell with `MIX_ENV=prod`. For example: `MIX_ENV=prod mix phx.server`. Documentation for the config can be found at [`docs/config.md`](docs/config.md)
* For these next steps, the default will be to run pleroma using the dev configuration file, `config/dev.secret.exs`. To run them using the prod config file, prefix each command at the shell with `MIX_ENV=prod`. For example: `MIX_ENV=prod mix phx.server`. Documentation for the config can be found at [`docs/config.md`](docs/config.md) in the repository, or at the "Configuration" page on <https://docs.pleroma.social>
* Run `mix ecto.migrate` to run the database migrations. You will have to do this again after certain updates.
* You can check if your instance is configured correctly by running it with `mix phx.server` and checking the instance info endpoint at `/api/v1/instance`. If it shows your uri, name and email correctly, you are configured correctly. If it shows something like `localhost:4000`, your configuration is probably wrong, unless you are running a local development setup.
* The common and convenient way for adding HTTPS is by using Nginx as a reverse proxy. You can look at example Nginx configuration in `installation/pleroma.nginx`. If you need TLS/SSL certificates for HTTPS, you can look get some for free with letsencrypt: <https://letsencrypt.org/>. The simplest way to obtain and install a certificate is to use [Certbot.](https://certbot.eff.org) Depending on your specific setup, certbot may be able to get a certificate and configure your web server automatically.
......
# Admin tasks
## Important
If your instance is running in prod mode (most likely it is) make sure to prefix every command with `MIX_ENV=prod`.
## User management
It is possible to obtain a list of all available tasks with their options by executing `mix help pleroma.user`
### Adding users
Use `mix pleroma.user invite` to generate an invite link for a new user.
Also, `mix pleroma.user new NICKNAME EMAIL [OPTION...]` can be used to register an account.
### Making a user a moderator/admin/locked
Run `mix pleroma.user set username --[no-]moderator` to make user a moderator or remove the moderator status.
To make the user admin or locked use `mix pleroma.user set NICKNAME --[no-]admin` and `mix pleroma.user set NICKNAME --[no-]locked` respectively
### Resetting a password
Run `mix pleroma.user reset_password NICKNAME` to generate a password reset link that you can then send to the user.
### Banning users
Run `mix pleroma.user rm NICKNAME` to remove a local account.
To deactivate(block from the server completely)/reactivate local and remote user accounts run:
`mix pleroma.user toggle_activated NICKNAME@instancename`
## Relay managment
It is possible to obtain a list of all available tasks with their options by executing `mix help pleroma.relay`
### Following a relay
Run `mix pleroma.relay follow RELAY_URL`
### Unfollowing a relay
Run `mix pleroma.relay unfollow RELAY_URL`
# Backup your instance
1. Stop the Pleroma service.
2. Go to the working directory of Pleroma (default is `/opt/pleroma`)
3. Run `sudo -Hu postgres pg_dump -d <pleroma_db> --format=custom -f </path/to/backup_location/pleroma.pgdump>`
4. Copy `pleroma.pgdump`, `config/prod.secret.exs` and the `uploads` folder to your backup destination. If you have other modifications, copy those changes too.
5. Restart the Pleroma service.
## Restore your instance
1. Stop the Pleroma service.
2. Go to the working directory of Pleroma (default is `/opt/pleroma`)
3. Copy the above mentioned files back to their original position.
4. Run `sudo -Hu postgres pg_restore -d <pleroma_db> -v -1 </path/to/backup_location/pleroma.pgdump>`
5. Restart the Pleroma service.
# Updating your instance
1. Stop the Pleroma service.
2. Go to the working directory of Pleroma (default is `/opt/pleroma`)
3. Run `git pull`. This pulls the latest changes from upstream.
4. Run `mix deps.get`. This pulls in any new dependencies.
5. Run `mix ecto.migrate`[^1]. This task performs database migrations, if there were any.
6. Restart the Pleroma service.
[^1]: Prefix with `MIX_ENV=prod` to run it using the production config file.
# Admin API
# Admin API
Authentication is required and the user must be an admin.
......
......@@ -61,7 +61,10 @@ Request parameters can be passed via [query strings](https://en.wikipedia.org/wi
"cover_photo": "https://pleroma.soykaf.com/images/banner.png",
"created_at": "Tue Dec 18 16:55:56 +0000 2018",
"default_scope": "public",
"description": "blushy-crushy fediverse idol + pleroma dev\nlet's be friends \nぷれろまの生徒会長。謎の外人。日本語OK. \n公主病.",
"description": "blushy-crushy fediverse idol + pleroma dev
let's be friends
ぷれろまの生徒会長。謎の外人。日本語OK.
公主病.",
"description_html": "blushy-crushy fediverse idol + pleroma dev.<br />let's be friends <br />ぷれろまの生徒会長。謎の外人。日本語OK. <br />公主病.",
"favourites_count": 0,
"fields": [],
......
# General tips for customizing Pleroma FE
There are some configuration scripts for Pleroma BE and FE:
1. `config/prod.secret.exs`
1. `config/config.exs`
1. `priv/static/static/config.json`
The `prod.secret.exs` affects first. `config.exs` is for fallback or default. `config.json` is for GNU-social-BE-Pleroma-FE instances.
Usually all you have to do is:
1. Copy the section in the `config/config.exs` which you want to activate.
1. Paste into `config/prod.secret.exs`.
1. Edit `config/prod.secret.exs`.
1. Restart the Pleroma daemon.
`prod.secret.exs` is for the `MIX_ENV=prod` environment. `dev.secret.exs` is for the `MIX_ENV=dev` environment respectively.
# Custom emoji
# Custom Emoji
To add custom emoji:
* Add the image file(s) to `priv/static/emoji/custom`
......
# Hardening your instance
Here are some suggestions which improve the security of parts of your Pleroma instance.
## Configuration file
These changes should go into `prod.secret.exs` or `dev.secret.exs`, depending on your `MIX_ENV` value.
### `http`
> Recommended value: `[ip: {127, 0, 0, 1}]`
This sets the Pleroma application server to only listen to the localhost interface. This way, you can only reach your server over the Internet by going through the reverse proxy. By default, Pleroma listens on all interfaces.
### `secure_cookie_flag`
> Recommended value: `true`
This sets the `secure` flag on Pleroma’s session cookie. This makes sure, that the cookie is only accepted over encrypted HTTPs connections. This implicitly renames the cookie from `pleroma_key` to `__Host-pleroma-key` which enforces some restrictions. (see [cookie prefixes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#Cookie_prefixes))
### `:http_security`
> Recommended value: `true`
This will send additional HTTP security headers to the clients, including:
* `X-XSS-Protection: "1; mode=block"`
* `X-Permitted-Cross-Domain-Policies: "none"`
* `X-Frame-Options: "DENY"`
* `X-Content-Type-Options: "nosniff"`
* `X-Download-Options: "noopen"`
A content security policy (CSP) will also be set:
```csp
content-security-policy:
default-src 'none';
base-uri 'self';
frame-ancestors 'none';
img-src 'self' data: https:;
media-src 'self' https:;
style-src 'self' 'unsafe-inline';
font-src 'self';
script-src 'self';
connect-src 'self' wss://example.tld;
manifest-src 'self';
upgrade-insecure-requests;
```
#### `sts`
> Recommended value: `true`
An additional “Strict transport security” header will be sent with the configured `sts_max_age` parameter. This tells the browser, that the domain should only be accessed over a secure HTTPs connection.
#### `ct_max_age`
An additional “Expect-CT” header will be sent with the configured `ct_max_age` parameter. This enforces the use of TLS certificates that are published in the certificate transparency log. (see [Expect-CT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect-CT))
#### `referrer_policy`
> Recommended value: `same-origin`
If you click on a link, your browser’s request to the other site will include from where it is coming from. The “Referrer policy” header tells the browser how and if it should send this information. (see [Referrer policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy))
## systemd
A systemd unit example is provided at `installation/pleroma.service`.
### PrivateTmp
> Recommended value: `true`
Use private `/tmp` and `/var/tmp` folders inside a new file system namespace, which are discarded after the process stops.
### ProtectHome
> Recommended value: `true`
The `/home`, `/root`, and `/run/user` folders can not be accessed by this service anymore. If your Pleroma user has its home folder in one of the restricted places, or use one of these folders as its working directory, you have to set this to `false`.
### ProtectSystem
> Recommended value: `full`
Mount `/usr`, `/boot`, and `/etc` as read-only for processes invoked by this service.
### PrivateDevices
> Recommended value: `true`
Sets up a new `/dev` mount for the process and only adds API pseudo devices like `/dev/null`, `/dev/zero` or `/dev/random` but not physical devices. This may not work on devices like the Raspberry Pi, where you need to set this to `false`.
### NoNewPrivileges
> Recommended value: `true`
Ensures that the service process and all its children can never gain new privileges through `execve()`.
### CapabilityBoundingSet
> Recommended value: `~CAP_SYS_ADMIN`
Drops the sysadmin capability from the daemon.
# How to change the port or IP Pleroma listens to
To change the port or IP Pleroma listens to, head over to your generated config inside the Pleroma folder at config/prod.secret.exs and edit the following according to your needs.
```
config :pleroma, Pleroma.Web.Endpoint,
[...]
http: [ip: {127, 0, 0, 1}, port: 4000]
```
# How to activate mediaproxy
## Explanation
Without the `mediaproxy` function, Pleroma don't store any remote content like pictures, video etc. locally. So every time you open Pleroma, the content is loaded from the source server, from where the post is coming. This can result in slowly loading content or/and increased bandwidth usage on the source server.
With the `mediaproxy` function you can use the cache ability of nginx, to cache these content, so user can access it faster, cause it's loaded from your server.
## Activate it
* Edit your nginx config and add the following location:
```
location /proxy {
proxy_cache pleroma_media_cache;
proxy_cache_lock on;
proxy_pass http://localhost:4000;
}
```
Also add the following on top of the configuration, outside of the `server` block:
```
proxy_cache_path /tmp/pleroma-media-cache levels=1:2 keys_zone=pleroma_media_cache:10m max_size=10g inactive=720m use_temp_path=off;
```
If you came here from one of the installation guides, take a look at the example configuration `/installation/pleroma.nginx`, where this part is already included.
* Append the following to your `prod.secret.exs` or `dev.secret.exs` (depends on which mode your instance is running):
```
config :pleroma, :media_proxy,
enabled: true,
redirect_on_failure: true
#base_url: "https://cache.pleroma.social"
```
If you want to use a subdomain to serve the files, uncomment `base_url`, change the url and add a comma after `true` in the previous line.
* Restart nginx and Pleroma
# How to configure upstream proxy for federation
If you want to proxify all http requests (e.g. for TOR) that pleroma makes to an upstream proxy server, edit you config file (`dev.secret.exs` or `prod.secret.exs`) and add the following:
```
config :pleroma, :http,
proxy_url: "127.0.0.1:8123"
```
The other way to do it, for example, with Tor you would most likely add something like this:
```
config :pleroma, :http, proxy_url: {:socks5, :localhost, 9050}
```
# How to activate user recommendation (Who to follow panel)
![who-to-follow-panel-small](/uploads/9de1b1300436c32461d272945f1bc23e/who-to-follow-panel-small.png)
To show the *who to follow* panel, edit `config/prod.secret.exs` in the Pleroma backend. Following code activates the *who to follow* panel:
```elixir
config :pleroma, :suggestions,
enabled: true,
third_party_engine:
"http://vinayaka.distsn.org/cgi-bin/vinayaka-user-match-suggestions-api.cgi?{{host}}+{{user}}",
timeout: 300_000,
limit: 23,
web: "https://vinayaka.distsn.org/?{{host}}+{{user}}"
```
`config/config.exs` already includes this code, but `enabled:` is `false`.
`/api/v1/suggestions` is also provided when *who to follow* panel is enabled.
For advanced customization, following code shows the newcomers of the fediverse at the *who to follow* panel:
```elixir
config :pleroma, :suggestions,
enabled: true,
third_party_engine:
"http://vinayaka.distsn.org/cgi-bin/vinayaka-user-new-suggestions-api.cgi?{{host}}+{{user}}",
timeout: 60_000,
limit: 23,
web: "https://vinayaka.distsn.org/user-new.html"
```
# I2P Federation
# I2P Federation and Accessability
This guide is going to focus on the Pleroma federation aspect. The actual installation is neatly explained in the official documentation, and more likely to remain up-to-date.
It might be added to this guide if there will be a need for that.
We're going to use I2PD for its lightweightness over the official client.
Follow the documentation according to your distro: https://i2pd.readthedocs.io/en/latest/user-guide/install/#installing
How to run it: https://i2pd.readthedocs.io/en/latest/user-guide/run/
## I2P Federation
There are 2 ways to go about this.
One using the config, and one using external software (fedproxy). The external software works better so far.
### Using the Config
**Warning:** So far, everytime I followed this way of federating using I2P, the rest of my federation stopped working. I'm leaving this here in case it will help with making it work.
Assuming you're running in prod, cd to your Pleroma folder and append the following to `config/prod.secret.exs`:
```
config :pleroma, :http, proxy_url: {:socks5, :localhost, 4447}
```
And then run the following:
```
su pleroma
MIX_ENV=prod mix deps.get
MIX_ENV=prod mix ecto.migrate
exit
```
You can restart I2PD here and finish if you don't wish to make your instance viewable or accessible over I2P.
```
systemctl stop i2pd.service --no-block
systemctl start i2pd.service
```
*Notice:* The stop command initiates a graceful shutdown process, i2pd stops after finishing to route transit tunnels (maximum 10 minutes).
You can change the socks proxy port in `/etc/i2pd/i2pd.conf`.
### Using Fedproxy
Fedproxy passes through clearnet requests direct to where they are going. It doesn't force anything over Tor.
To use [fedproxy](https://github.com/majestrate/fedproxy) you'll need to install Golang.
```
apt install golang
```
Use a different user than pleroma or root. Run the following to add the Gopath to your ~/.bashrc.
```
echo "export GOPATH=/home/ren/.go" >> ~/.bashrc
```
Restart that bash session (you can exit and log back in).
Run the following to get fedproxy.
```
go get -u github.com/majestrate/fedproxy$
cp $(GOPATH)/bin/fedproxy /usr/local/bin/fedproxy
```
And then the following to start it for I2P only.
```
fedproxy 127.0.0.1:2000 127.0.0.1:4447
```
If you want to also use it for Tor, add `127.0.0.1:9050` to that command.
You'll also need to modify your Pleroma config.
Assuming you're running in prod, cd to your Pleroma folder and append the following to `config/prod.secret.exs`:
```
config :pleroma, :http, proxy_url: {:socks5, :localhost, 2000}
```
And then run the following:
```
su pleroma
MIX_ENV=prod mix deps.get
MIX_ENV=prod mix ecto.migrate
exit
```
You can restart I2PD here and finish if you don't wish to make your instance viewable or accessible over I2P.
```
systemctl stop i2pd.service --no-block
systemctl start i2pd.service
```
*Notice:* The stop command initiates a graceful shutdown process, i2pd stops after finishing to route transit tunnels (maximum 10 minutes).
You can change the socks proxy port in `/etc/i2pd/i2pd.conf`.
## I2P Instance Access
Make your instance accessible using I2P.
Add the following to your I2PD config `/etc/i2pd/tunnels.conf`:
```
[pleroma]
type = http
host = 127.0.0.1
port = 14447
keys = pleroma.dat
```
Restart I2PD:
```
systemctl stop i2pd.service --no-block
systemctl start i2pd.service
```
*Notice:* The stop command initiates a graceful shutdown process, i2pd stops after finishing to route transit tunnels (maximum 10 minutes).
Now you'll have to find your address.
To do that you can download and use I2PD tools.[^1]
Or you'll need to access your web-console on localhost:7070.
If you don't have a GUI, you'll have to SSH tunnel into it like this:
`ssh -L 7070:127.0.0.1:7070 user@ip -p port`.
Now you can access it at localhost:7070.
Go to I2P tunnels page. Look for Server tunnels and you will see an address that ends with `.b32.i2p` next to "pleroma".
This is your site's address.
### I2P-only Instance
If creating an I2P-only instance, open `config/prod.secret.exs` and under "config :pleroma, Pleroma.Web.Endpoint," edit "https" and "port: 443" to the following:
```
url: [host: "i2paddress", scheme: "http", port: 80],
```
In addition to that, replace the existing nginx config's contents with the example below.
### Existing Instance (Clearnet Instance)
If not an I2P-only instance, add the nginx config below to your existing config at `/etc/nginx/sites-enabled/pleroma.nginx`.
And for both cases, disable CSP in Pleroma's config (STS is disabled by default) so you can define those yourself seperately from the clearnet (if your instance is also on the clearnet).
Copy the following into the `config/prod.secret.exs` in your Pleroma folder (/home/pleroma/pleroma/):
```
config :pleroma, :http_security,
enabled: false
```
Use this as the Nginx config:
```
proxy_cache_path /tmp/pleroma-media-cache levels=1:2 keys_zone=pleroma_media_cache:10m max_size=10g inactive=720m use_temp_path=off;
# The above already exists in a clearnet instance's config.
# If not, add it.
server {
listen 127.0.0.1:14447;
server_name youri2paddress;
# Comment to enable logs
access_log /dev/null;
error_log /dev/null;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/activity+json application/atom+xml;
client_max_body_size 16m;
location / {
add_header X-XSS-Protection "1; mode=block";
add_header X-Permitted-Cross-Domain-Policies none;
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header Referrer-Policy same-origin;
add_header X-Download-Options noopen;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $http_host;
proxy_pass http://localhost:4000;
client_max_body_size 16m;
}
location /proxy {
proxy_cache pleroma_media_cache;
proxy_cache_lock on;
proxy_ignore_client_abort on;
proxy_pass http://localhost:4000;
}
}
```
reload Nginx:
```
systemctl stop i2pd.service --no-block
systemctl start i2pd.service
```
*Notice:* The stop command initiates a graceful shutdown process, i2pd stops after finishing to route transit tunnels (maximum 10 minutes).
You should now be able to both access your instance using I2P and federate with other I2P instances!
[^1]: [I2PD tools](https://github.com/purplei2p/i2pd-tools) to print information about a router info file or an I2P private key, generate an I2P private key, and generate vanity addresses.
### Possible Issues
Will be added when encountered.
# Message Rewrite Facility configuration
# Message Rewrite Facility
The Message Rewrite Facility (MRF) is a subsystem that is implemented as a series of hooks that allows the administrator to rewrite or discard messages.
Possible uses include:
......@@ -70,7 +70,7 @@ As discussed above, the MRF system is a modular system that supports pluggable p
For example, here is a sample policy module which rewrites all messages to "new message content":
```!elixir
```elixir
# This is a sample MRF policy which rewrites all Notes to have "new message
# content."
defmodule Site.RewritePolicy do
......@@ -116,4 +116,4 @@ config :pleroma, :instance,
]
```
Please note that the Pleroma developers consider custom MRF policy modules to fall under the purview of the AGPL. As such, you are obligated to release the sources to your custom MRF policy modules upon request.
\ No newline at end of file
Please note that the Pleroma developers consider custom MRF policy modules to fall under the purview of the AGPL. As such, you are obligated to release the sources to your custom MRF policy modules upon request.
# Easy Onion Federation (Tor)
Tor can free people from the necessity of a domain, in addition to helping protect their privacy. As Pleroma's goal is to empower the people and let as many as possible host an instance with as little resources as possible, the ability to host an instance with a small, cheap computer like a RaspberryPi along with Tor, would be a great way to achieve that.
In addition, federating with such instances will also help furthering that goal.
This is a guide to show you how it can be easily done.
This guide assumes you already got Pleroma working, and that it's running on the default port 4000.
Currently only has an Nginx example.
To install Tor on Debian / Ubuntu:
```
apt -yq install tor
```
If using an old server version (older than Debian Stretch or Ubuntu 18.04), install from backports or PPA.
I recommend using a newer server version instead.
To have the newest, V3 onion addresses (which I recommend) in Debian, install Tor from backports.
If you do not have backports, uncomment the stretch-backports links at the end of `/etc/apt/sources.list`.
Then install:
```
apt update
apt -t stretch-backports -yq install tor
```
**WARNING:** Onion instances not using a Tor version supporting V3 addresses will not be able to federate with you.
Create the hidden service for your Pleroma instance in `/etc/tor/torrc`:
```
HiddenServiceDir /var/lib/tor/pleroma_hidden_service/
HiddenServicePort 80 127.0.0.1:8099
HiddenServiceVersion 3 # Remove if Tor version is below 0.3 ( tor --version )
```
Restart Tor to generate an adress:
```
systemctl restart tor@default.service
```
Get the address:
```
cat /var/lib/tor/pleroma_hidden_service/hostname
```
# Federation
Next, edit your Pleroma config.
If running in prod, cd to your Pleroma directory, edit `config/prod.secret.exs`
and append this line:
```
config :pleroma, :http, proxy_url: {:socks5, :localhost, 9050}
```
In your Pleroma directory, assuming you're running prod,
run the following:
```
su pleroma
MIX_ENV=prod mix deps.get
MIX_ENV=prod mix ecto.migrate
exit
```
restart Pleroma (if using systemd):
```
systemctl restart pleroma
```
# Tor Instance Access
Make your instance accessible using Tor.
## Tor-only Instance
If creating a Tor-only instance, open `config/prod.secret.exs` and under "config :pleroma, Pleroma.Web.Endpoint," edit "https" and "port: 443" to the following:
```
url: [host: "onionaddress", scheme: "http", port: 80],
```
In addition to that, replace the existing nginx config's contents with the example below.
## Existing Instance (Clearnet Instance)
If not a Tor-only instance,
add the nginx config below to your existing config at `/etc/nginx/sites-enabled/pleroma.nginx`.
---
For both cases, disable CSP in Pleroma's config (STS is disabled by default) so you can define those yourself seperately from the clearnet (if your instance is also on the clearnet).
Copy the following into the `config/prod.secret.exs` in your Pleroma folder (/home/pleroma/pleroma/):
```
config :pleroma, :http_security,
enabled: false
```
Use this as the Nginx config:
```
proxy_cache_path /tmp/pleroma-media-cache levels=1:2 keys_zone=pleroma_media_cache:10m max_size=10g inactive=720m use_temp_path=off;
# The above already exists in a clearnet instance's config.
# If not, add it.
server {
listen 127.0.0.1:8099;
server_name youronionaddress;
# Comment to enable logs
access_log /dev/null;
error_log /dev/null;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/activity+json application/atom+xml;
client_max_body_size 16m;
location / {
add_header X-XSS-Protection "1; mode=block";
add_header X-Permitted-Cross-Domain-Policies none;
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header Referrer-Policy same-origin;
add_header X-Download-Options noopen;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $http_host;