如何使用Docker,Nginx和Letsencrypt设置简单且安全的反向代理

by Kasper Siig

卡斯珀·西格(Kasper Siig)

介绍 (Introduction)

Ever tried setting up some sort of server at home? Where you have to open a new port for every service? And have to remember what port goes to which service, and what your home ip is? This is definitely something that works, and people have been doing it for the longest time.

曾经尝试在家中设置某种服务器吗? 您必须在哪里为每个服务打开一个新端口? 并且必须记住哪个端口连接到哪个服务以及您的家庭IP是什么? 这绝对是行得通的,而且人们已经做了很长时间了。

However, wouldn’t it be nice to type plex.example.com, and have instant access to your media server? This is exactly what a reverse proxy will do for you, and combining it with Docker, it’s easier than ever.

但是,输入plex.example.com并立即访问您的媒体服务器不是很好吗? 这正是反向代理将为您完成的工作,并将其与Docker结合使用,比以往任何时候都更加容易。

先决条件 (Prerequisites)

Docker和Docker-Compose (Docker & Docker-Compose)

You should have Docker version 17.12.0+, and Compose version 1.21.0+.

您应该拥有Docker版本17.12.0+和Compose版本1.21.0+。

(Domain)

You should have a domain set up, and have an SSL Certificate associated with it. If you don’t have one, then follow my guide here on how to get a free one with LetsEncrypt.

您应该设置一个域,并具有与之关联的SSL证书。 如果您还没有,请按照我的指南进行操作,了解如何使用LetsEncrypt获得免费的。

本文涵盖的内容 (What This Article Will Cover)

I’m a firm believer in understanding what you are doing. There was a time where I would follow guides, and have no clue on how to troubleshoot failures. If that’s how you want to do it, here’s a great tutorial, which covers how to set it up. While my articles are lengthy, you should end up with an understanding of how it all works.

我坚信您在做什么。 曾经有一段时间我会遵循指南,但对如何解决故障一无所知。 如果这是您想要的方法,那么这是一个很棒的教程 ,其中涵盖了如何进行设置。 尽管我的文章冗长,但您应该最终了解它们的工作方式。

What you will learn here, is what a reverse proxy is, how to set it up, and how you can secure it. I do my best to divide the subject into sections, divided by headers, so feel free to jump over a section, if you feel like it. I recommend reading the entire article one time first, before starting to set it up.

您将在这里学到什么是反向代理,如何设置它以及如何保护它。 我会尽力将主题划分为多个部分,并按标题将其划分,因此,如果您愿意,可以随时跳过该部分。 我建议您在开始设置之前先阅读整篇文章。

什么是反向代理? (What is a Reverse Proxy?)

常规代理 (Regular Proxy)

Let’s start with the concept of a regular proxy. While this is a term that’s very prevalent in the tech community, it is not the only place it’s used. A proxy means that information is going through a third party, before getting to the location.

让我们从常规代理的概念开始。 虽然这是一个在技术社区中非常普遍的术语,但并不是唯一使用它的地方。 代理意味着信息在到达该位置之前正在经过第三方。

Say that you don’t want a service to know your IP, you can use a proxy. A proxy is a server that has been set up specifically for this purpose. If the proxy server you are using is located in, for example, Amsterdam, the IP that will be shown to the outside world is the IP from the server in Amsterdam. The only ones who will know your IP are the ones in control of the proxy server.

假设您不希望服务知道您的IP,则可以使用代理。 代理是专门为此目的而设置的服务器。 如果您使用的代理服务器位于(例如)阿姆斯特丹,则向外界显示的IP是阿姆斯特丹服务器的IP。 唯一会知道您的IP的人是控制代理服务器的人。

反向代理 (Reverse Proxy)

To break it into simple terms, a proxy will add a layer of masking. It’s the same concept in a reverse proxy, except instead of masking outgoing connections (you accessing a webserver), it’s the incoming connections (people accessing your webserver) that will be masked. You simply provide a URL like example.com, and whenever people access that URL, your reverse proxy will take care of where that request goes.

为了将其分解为简单的术语,代理将添加一层遮罩。 在反向代理中,这是相同的概念,不同之处在于,不是屏蔽传出的连接(您访问Web服务器),而是屏蔽传入的连接(人们访问您的Web服务器)。 您只需提供一个类似于example.com的URL,每当人们访问该URL时,您的反向代理就会处理该请求的去向。

Let’s say you have two servers set up on your internal network. Server1 is on 192.168.1.10, and Server2 is on 192.168.1.20. Right now your reverse proxy is sending requests coming from example.com to Server1. One day you have some updates to the webpage. Instead of taking the website down for maintenance, you just make the new setup on Server2. One you’re done, you simply change a single line in your reverse proxy, and now requests are sent to Server2. Assuming the reverse proxy is setup correctly, you should have absolutely no downtime.

假设您在内部网络上设置了两个服务器。 Server1位于192.168.1.10上 ,而Server2位于192.168.1.20上。 现在,您的反向代理正在将来自example.com的请求发送到Server1。 有一天,您会对网页进行一些更新。 无需关闭网站进行维护,您只需在Server2上进行新设置即可。 完成后,您只需在反向代理中更改一行,然后将请求发送到Server2。 假设反向代理正确设置,那么您应该绝对没有停机时间。

But perhaps the biggest advantage of having a reverse proxy, is that you can have services running on a multitude of ports, but you only have to open ports 80 and 443, HTTP and HTTPS respectively. All requests will be coming into your network on those two ports, and the reverse proxy will take care of the rest. All of this will make sense once we start setting the proxy up.

但是拥有反向代理的最大优点也许是,您可以在多个端口上运行服务,但是您只需要分别打开端口80和443,HTTP和HTTPS。 所有请求都将通过这两个端口进入您的网络,反向代理将处理其余的请求。 一旦我们开始设置代理,所有这些都将变得有意义。

设置容器 (Setting Up the Container)

该怎么办 (What to Do)

docker-compose.yaml:

docker-compose.yaml

version: '3'

services:
  reverse:
    container_name: reverse
    hostname: reverse
    image: nginx
    ports:
      - 80:80
      - 443:443
    volumes:
      - <path/to/your/config>:/etc/nginx
      - <path/to/your/certs>:/etc/ssl/private

First of all, you should add a new service to your docker-compose file. You can call it whatever you prefer, in this case I’ve chosen reverse. Here I’ve just chosen nginx as the image, however in a production environment, it’s usually a good idea to specify a version in case there are ever any breaking changes in future updates.

首先,您应该向docker-compose文件添加新服务。 您可以随意命名,在这种情况下,我选择了reverse 。 在这里,我只是选择nginx作为映像,但是在生产环境中,通常最好指定一个版本,以防将来的更新中发生任何重大更改。

Then you should volume bind two folders. /etc/nginx is where all your configuration files are stored, and /etc/ssl/private is where your SSL certificates are stored. It is VERY important that your config folder does NOT exist on your host first time you’re starting the container. When you start your container through docker-compose, it will automatically create the folder and populate it with the contents of the container. If you have created an empty config folder on your host, it will mount that, and the folder inside the container will be empty.

然后,您应该将两个文件夹进行卷绑定。 / etc / nginx是存储所有配置文件的位置, / etc / ssl / private是存储SSL证书的位置。 首次启动容器时,主机上不存在配置文件夹,这一点非常重要。 通过docker-compose启动容器时,它将自动创建文件夹并使用容器的内容填充该文件夹。 如果您在主机上创建了一个空的config文件夹,它将安装该文件夹,并且容器内的文件夹将为空。

为什么有效 (Why it Works)

There isn’t much to this part. Mostly it’s like starting any other container with docker-compose. What you should notice here is that you are binding port 80 and 443. This is where all requests will come in, and they will be forwarded to whatever service you will specify.

这部分内容不多。 通常,这就像使用docker-compose启动任何其他容器一样。 您应该在此处注意的是,您正在绑定端口80和443。这是所有请求进入的位置,它们将被转发到您指定的任何服务。

配置Nginx (Configuring Nginx)

该怎么办 (What to Do)

Now you should have a config folder on your host. Changing to that directory, you should see a bunch of different files and a folder called conf.d. It’s inside conf.d that all your configuration files will be placed. Right now there’s a single default.conf file, you can go ahead and delete that.

现在,您的主机上应该有一个配置文件夹。 切换到该目录,您应该看到一堆不同的文件和一个名为conf.d的文件夹。 在conf.d内部,将放置所有配置文件。 现在只有一个default.conf文件,您可以继续删除它。

Still inside conf.d, create two folders: sites-available and sites-enabled. Navigate into sites-available and create your first configuration file. Here we’re going to setup an entry for Plex, but feel free to use another service that you have set up if you like. It doesn’t really matter what the file is called, however I prefer to name it like plex.conf.

仍在conf.d内部,创建两个文件夹: sites-availablesites-enabled 。 导航到sites-available并创建第一个配置文件。 在这里,我们将为Plex设置一个条目,但是如果您愿意,可以随时使用您已经设置的另一个服务。 究竟调用什么文件并不重要,但是我更喜欢将其命名为plex.conf

Now open the file, and enter the following:

现在打开文件,然后输入以下内容:

upstream plex {
  server        plex:32400;
}

server {
  listen        80;
  server_name   plex.example.com;

  location / {
    proxy_pass  http://plex;
  }
}

Go into the sites-enabled directory, and enter the following command:

转到sites-enabled目录,然后输入以下命令:

ln -s ../sites-available/plex.conf .

This will create a symbolic link to the file in the other folder. Now there’s only one thing left, and that is to change the nginx.conf file in the config folder. If you open the file, you should see the following as the last line:

这将创建一个指向另一个文件夹中文件的符号链接。 现在只剩下一件事了,那就是更改config文件夹中的nginx.conf文件。 如果打开文件,则应在最后一行看到以下内容:

include /etc/nginx/conf.d/*.conf;

Change that to:

更改为:

include /etc/nginx/conf.d/sites-enabled/*.conf;

In order to get the reverse proxy to actually work, we need to reload the nginx service inside the container. From the host, run docker exec <container-name> nginx -t. This will run a syntax checker against your configuration files. This should output that the syntax is ok. Now run docker exec <container-name> nginx -s reload. This will send a signal to the nginx process that it should reload, and congratulations! You now have a running reverse proxy, and should be able to access your server at plex.example.com (assuming that you have forwarded port 80 to your host in your router).

为了使反向代理真正起作用,我们需要在容器内重新加载nginx服务。 从主机运行docker exec <container-name> nginx -t 。 这将针对您的配置文件运行语法检查器。 这应该输出语法正常。 现在运行docker exec <container-name> nginx -s reload 。 这将向nginx进程发送一个信号,它应该重新加载,并表示祝贺! 您现在拥有一个正在运行的反向代理,并且应该能够通过plex.example.com访问服务器(假设您已将端口80转发到路由器中的主机)。

Even though your reverse proxy is working, you are running on HTTP, which provides no encryption whatsoever. The next part will be how to secure your proxy, and get a perfect score on SSL Labs.

即使反向代理正常工作,您仍在HTTP上运行,该协议不提供任何加密。 下一部分将介绍如何保护您的代理,以及如何在SSL Labs上获得满分。

为什么有效 (Why it Works)

The Configuration File

配置文件

As you can see, the plex.conf file consists of two parts. An upstream part and a server part. Let’s start with the server part. This is where you are defining the port receiving the incoming requests, what domain this configuration should match, and where it should be sent to.

如您所见, plex.conf文件由两部分组成。 upstream部分和server部分。 让我们从server部分开始。 在这里,您可以定义接收传入请求的端口,此配置应匹配的域以及将其发送到的位置。

The way this server is being set up, you should make a file for each service that you want to proxy requests to, so obviously you need some way to distinguish which file to receive each request. This is what the server-name directive does. Below that we have the location directive.

该服务器的设置方式,应该为要代理请求的每个服务创建一个文件,因此显然您需要某种方式来区分接收每个请求的文件。 这就是server-name指令的作用。 在此之下,我们有location指令。

In our case we only need one location, however you can have as many location directives as you want. Imagine you have a website with a frontend and a backend. Depending on the infrastructure you’re using, you’ll have the frontend as one container and the backend as another container. You could then have location / {} which will send requests to the frontend, and location /api/ {} which will send requests to the backend. Suddenly you have multiple services running on a single memorable domain.

在我们的情况下,我们只需要一个location ,但是您可以根据需要设置任意多个location指令。 想象一下,您有一个带有前端和后端的网站。 根据您使用的基础架构,您将前端作为一个容器,将后端作为另一个容器。 然后,您可以使用location / {}将请求发送到前端,以及location /api/ {}将请求发送到后端。 突然,您在一个难忘的域上运行了多个服务。

As for the upstream part, that can be used for load-balancing. If you’re interested in learning more about how that works, you can look at the official docs here. For our simple case, you just define the hostname or ip address of the service you want to proxy to, and what port is should be proxied to, and then refer to the upstream name in the location directive.

至于upstream部分,可用于负载平衡。 如果您想了解更多有关其工作原理的信息,可以在此处查看官方文档 。 对于我们的简单情况,您只需定义要代理的服务的主机名或IP地址,以及应该代理的端口,然后在location指令中引用上游名称。

Hostname Vs. IP Address

主机名与 IP地址

To understand what a hostname is, let’s make an example. Say you are on your home network 192.168.1.0. You then set up a server on 192.168.1.10 and run Plex on it. You can now access Plex on 192.168.1.10:32400, as long as you are still on the same network. Another possibility is to give the server a hostname. In this case we’ll give it the hostname plex. Now you can access Plex by entering plex:32400 in your browser!

要了解什么是主机名,让我们举个例子。 假设您在家庭网络192.168.1.0上。 然后,您在192.168.1.10上设置服务器,并在其上运行Plex。 现在,只要您仍在同一网络上,就可以访问192.168.1.10:32400上的 Plex。 另一种可能性是给服务器一个主机名。 在这种情况下,我们给它主机名plex 。 现在,您可以在浏览器中输入plex:32400来访问Plex!

This same concept was introduced to docker-compose in version 3. If you look at the docker-compose file earlier in this article, you’ll notice that I gave it a hostname: reverse directive. Now all other containers can access my reverse proxy by its hostname. One thing that’s very important to note, is that the service name has to be the same as the hostname. This is something that the creators of docker-compose chose to impose.

相同的概念在版本3中也引入到docker-compose中。如果您在本文前面查看docker-compose文件,您会注意到我给它指定了一个hostname: reverse指令。 现在,所有其他容器都可以通过其主机名访问我的反向代理。 需要特别注意的一件事是,服务名称必须与主机名相同。 这是docker-compose的创建者选择强加的。

Another really important thing to remember, is that by default docker containers are put on their own network. This means that you won’t be able to access your container by it’s hostname, if you’re sitting on your laptop on your host network. It is only the containers that are able to access each other through their hostname.

要记住的另一个非常重要的事情是,默认情况下,Docker容器位于其自己的网络上。 这意味着,如果您坐在主机网络上的笔记本电脑上,将无法通过其主机名访问容器。 只有容器能够通过其主机名相互访问。

So to sum it up and make it really clear. In your docker-compose file, add the hostname directive to your services. Most of the time your containers will get a new IP every time you restart the container, so referring to it via hostname, means it doesn’t matter what IP your container is getting.

因此,总结起来并使其很清楚。 在您的docker-compose文件中,将hostname指令添加到您的服务中。 大多数情况下,每次重新启动容器时,容器都会获得新的IP,因此通过主机名引用它意味着容器获得的IP无关紧要。

Sites-available & Sites-enabled

可用站点和启用站点

Why are we creating the sites-available and sites-enabled directories? This is not something of my creation. If you install Nginx on a server, you will see that it comes with these folders. However because Docker is built with microservices in mind, where one container should only ever do one thing, these folders are omitted in the container. We’re recreating them again, because of how we’re using the container.

我们为什么要创建sites-available目录和sites-enabled目录? 这不是我的创造。 如果在服务器上安装Nginx,您将看到这些文件夹随附。 但是,由于Docker是在考虑微服务的情况下构建的,因此一个容器只能做一件事,因此这些文件夹在容器中被省略。 由于我们使用容器的方式,我们正在重新创建它们。

And yes, you could definitely just make a sites-enabled folder, or directly host your configuration files in conf.d. Doing it this way, enables you to have passive configuration laying around. Say that you are doing maintenance, and don’t want to have the service active; you simply remove the symbolic link, and put it back when you want the service active again.

是的,您绝对可以仅创建一个sites-enabledsites-enabled文件夹,或者直接将您的配置文件托管在conf.d 。 这样,您就可以进行被动配置。 假设您正在进行维护,并且不想激活该服务; 您只需删除符号链接,并在您希望服务再次激活时放回它。

Symbolic Links

符号链接

Symbolic links are a very powerful feature of the operating system. I had personally never used them before setting up an Nginx server, but since then I’ve been using them everywhere I can. Say you are working on 5 different projects, but all these projects use the same file in some way. You can either copy the file into every project, and refer to it directly, or you can place the file in one place, and in those 5 projects make symlinks to that file.

符号链接是操作系统的一项非常强大的功能。 在设置Nginx服务器之前,我个人从未使用过它们,但是从那时起,我一直在尽可能地使用它们。 假设您正在处理5个不同的项目,但是所有这些项目都以某种方式使用同一文件。 您可以将文件复制到每个项目中,然后直接引用它,也可以将文件放在一个位置,然后在这5个项目中建立指向该文件的符号链接。

This gives two advantages: you take up 4 times less space than you otherwise would have, and then the most powerful of them all; change the file in one place, and it changes in all 5 projects at once! This was a bit of a sidestep, but I think it’s worth mentioning.

这有两个优点:您所需要的空间比其他方法少了4倍,然后它们是所有功能中最强大的; 在一个位置更改文件,即可一次在所有5个项目中更改! 这是一个回避,但我认为值得一提。

保护Nginx代理 (Securing Nginx Proxy)

该怎么办 (What to Do)

Go to your config folder, and create 3 files and fill them with the following input:

转到您的config文件夹,创建3个文件,并用以下输入填充它们:

common.conf:

common.conf

add_header Strict-Transport-Security    "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options              SAMEORIGIN;
add_header X-Content-Type-Options       nosniff;
add_header X-XSS-Protection             "1; mode=block";

common_location.conf:

common_location.conf

proxy_set_header    X-Real-IP           $remote_addr;
proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
proxy_set_header    X-Forwarded-Proto   $scheme;
proxy_set_header    Host                $host;
proxy_set_header    X-Forwarded-Host    $host;
proxy_set_header    X-Forwarded-Port    $server_port;

ssl.conf:

ssl.conf

ssl_protocols               TLSv1 TLSv1.1 TLSv1.2;
ssl_ecdh_curve              secp384r1;
ssl_ciphers                 "ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384 OLD_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256";
ssl_prefer_server_ciphers   on;
ssl_dhparam                 /etc/nginx/dhparams.pem;
ssl_certificate             /etc/ssl/private/fullchain.pem;
ssl_certificate_key         /etc/ssl/private/privkey.pem;
ssl_session_timeout         10m;
ssl_session_cache           shared:SSL:10m;
ssl_session_tickets         off;
ssl_stapling                on;
ssl_stapling_verify         on;

Now open the plex.conf file, and change it to the following (notice lines 6, 9, 10 & 14):

现在打开plex.conf文件,并将其更改为以下内容(注意第plex.conf和14行):

upstream plex {
  server        plex:32400;
}

server {
  listen        443 ssl;
  server_name   plex.example.com;

  include       common.conf;
  include       /etc/nginx/ssl.conf;

  location / {
    proxy_pass  http://plex;
    include     common_location.conf;
  }
}

Now go back to the root of your config folder, and run the following command:

现在回到配置文件夹的根目录,并运行以下命令:

openssl dhparam -out dhparams.pem 4096

This will take a long time to complete, even up to an hour in some cases.

这将需要很长时间才能完成,在某些情况下甚至可能需要一个小时。

If you followed my article on getting a LetsEncrypt SSL Certificate, your certificates should be located in </path/to/your/letsencrypt/config>/etc/letsencrypt/live/<domain>/ .

如果您按照我的有关获取LetsEncrypt SSL证书的文章进行操作,则您的证书应位于</path/to/your/letsencrypt/config>/etc/letsencrypt/live/<domain>/

When I helped a friend set this up on his system, we ran into some problems where it couldn’t open the files when they were located in that directory. Most likely the cause of some permissions problems. The easy solution to this is to make an SSL directory, like </path/to/your/nginx/config>/certs, and then mount that to the Nginx container’s /etc/ssl/private folder. In the newly created folder, you should then make symbolic links, to the certs in your LetsEncrypt’s config folder.

当我帮助一个朋友在他的系统上进行设置时,我们遇到了一些问题,当它们位于该目录中时无法打开文件。 最有可能是某些权限问题的原因。 一个简单的解决方案是创建一个SSL目录,例如</path/to/your/nginx/config>/certs ,然后将其安装到Nginx容器的/etc/ssl/private文件夹中。 在新创建的文件夹中,然后应建立符号链接,链接到LetsEncrypt的config文件夹中的证书。

When the openssl command is done running, you should run the docker exec <container-name> nginx -t to make sure that all the syntax is correct, and then reload it by running docker exec <container-name> nginx -s reload. At this point everything should be running, and you now have a working and perfectly secure reverse proxy!

openssl命令运行docker exec <container-name> nginx -t ,您应该运行docker exec <container-name> nginx -t以确保所有语法正确,然后通过运行docker exec <container-name> nginx -s reload 。 至此,所有内容都应已运行,并且您现在有了一个可以正常运行且安全的反向代理!

为什么有效 (Why it Works)

Looking in the plex.conf file, there is only one major change, and that is what port the reverse proxy is listening on, and telling it that it’s an ssl connection. Then there are 3 places where we’re including the 3 other files we made. While SSL is kind of secure by itself, these other files make it even more secure. However if for some reason you don’t want to include these files, you need to move the ssl-certificate and ssl-certificate-keyinside the .conf file. These are required to have, in order for an HTTPS connection to work.

plex.conf文件中,只有一个主要更改,那就是反向代理正在侦听的端口,并告诉它它是ssl连接。 然后在3个地方包含我们制作的其他3个文件。 尽管SSL本身是安全的,但其他文件使它更加安全。 但是,如果由于某些原因您不想包括这些文件,则需要在.conf文件中移动ssl-certificatessl-certificate-key 。 为了使HTTPS连接正常工作,必须具备这些功能。

Common.conf

Common.conf

Looking in the common.conf file, we add 4 different headers. Headers are something that the server sends to the browser on every response. These headers tell the browser to act a certain way, and it is then up to the browser to enforce these headers.

common.conf文件中,我们添加了4个不同的标题。 标头是服务器在每次响应时发送给浏览器的内容。 这些标头告诉浏览器采取某种方式,然后由浏览器强制执行这些标头。

Strict-Transport-Security (HSTS)

严格运输安全(HSTS)

This header tells the browser that connections should be made over HTTPS. When this header has been added, the browser won’t let you make plain HTTP connection to the server, ensuring that all communication is secure.

该标头告诉浏览器应该通过HTTPS建立连接。 添加此标头后,浏览器将不允许您与服务器建立纯HTTP连接,以确保所有通信都是安全的。

X-Frame-Options

X框架选项

When specifying this header, you are specifying whether or not other sites can embed your content into their sites. This can help avoid clickjacking attacks.

指定此标头时,您要指定其他站点是否可以将您的内容嵌入到其站点中。 这可以帮助避免点击劫持攻击。

X-Content-Type-Options

X内容类型选项

Say you have a site where users can upload files. There’s not enough validation on the files, so a user successfully uploads a php file to the server, where the server is expecting an image to be uploaded. The attacker may then be able to access the uploaded file. Now the server responds with an image, however the file’s MIME-type is text/plain. The browser will ‘sniff’ the file, and then render the php script, allowing the attacker to do RCE (Remote Code Execution).

假设您有一个网站,用户可以在其中上传文件。 文件上的验证不足,因此用户已成功将php文件上传到服务器,服务器希望在该服务器上上传图像。 然后,攻击者可能能够访问上载的文件。 现在,服务器以图像作为响应,但是文件的MIME类型是text/plain 。 浏览器将“嗅探”文件,然后呈现php脚本,从而使攻击者可以执行RCE(远程代码执行)。

With this header set to ‘nosniff’, the browser will not look at the file, and simply render it as whatever the server tells the browser that it is.

将此标头设置为“ nosniff”后,浏览器将不会查看该文件,而只是将其呈现为服务器告诉浏览器的文件。

X-XSS-Protection

X-XSS保护

While this header was more necessary in older browsers, it’s so easy to add that you might as well. Some XSS (Cross-site Scripting) attacks can be very intelligent, while some are very rudimentary. This header will tell browsers to scan for the simple vulnerabilities and block them.

尽管在较旧的浏览器中更需要此标头,但添加它非常容易,您也可以添加。 一些XSS(跨站点脚本)攻击可能非常聪明,而另一些则非常初级。 该标头将告诉浏览器扫描简单漏洞并将其阻止。

Common_location.conf

Common_location.conf

X-Real-IP

X-Real-IP

Because your servers are behind a reverse proxy, if you try to look at the requesting IP, you will always see the IP of the reverse proxy. This header is added so you can see which IP is actually requesting your service.

因为您的服务器位于反向代理的后面,所以如果您尝试查看请求的IP,您将始终看到反向代理的IP。 添加了此标头,以便您可以查看实际请求服务的IP。

X-Forwarded-For

X转发

Sometimes a users request will go through multiple clients before it reaches your server. This header includes an array of all those clients.

有时,一个用户请求将在到达您的服务器之前经过多个客户端。 此标头包含所有这些客户端的数组。

X-Forwarded-Proto

X转发协议

This header will show what protocol is being used between client and server.

该标题将显示客户端和服务器之间正在使用的协议。

Host

主办

This ensures that it’s possible to do a reverse DNS lookup on the domain name. It’s used when the server_name directive is different than what you are proxying to.

这样可以确保可以对域名进行反向DNS查找。 当server_name指令与您要代理的指令不同时使用。

X-Forwarded-Host

X转发主机

Shows what the real host of the request is instead of the reverse proxy.

显示请求的真实主机是什么,而不是反向代理。

X-Forwarded-Port

X转发端口

Helps identify what port the client requested the server on.

帮助识别客户端请求服务器的端口。

Ssl.conf

Ssl.conf

SSL is a huge topic in and of itself, and too big to start explaining in this article. There are many great tutorials out there on how SSL handshakes work, and so on. If you want to look into this specific file, I suggest looking at the protocols and ciphers being used, and what difference they make.

SSL本身就是一个巨大的话题,太大了,无法在本文中进行介绍。 关于SSL握手的工作原理,有很多很棒的教程,等等。 如果您想查看此特定文件,建议您查看所使用的协议和密码,以及它们之间的区别。

将HTTP重定向到HTTPS (Redirecting HTTP to HTTPS)

The observant ones have maybe noticed that we are only ever listening on port 443 in this secure version. This would mean that anyone trying to access the site via https://* would get through, but trying to connect through http://* would just get an error. Luckily there’s a really easy fix to this. Make a redirect.conf file with the following contents:

细心的人可能已经注意到,我们只在此安全版本中监听端口443。 这意味着任何试图通过https:// *访问该网站的人都会通过,但是尝试通过http:// *进行连接只会得到一个错误。 幸运的是,这确实很容易解决。 制作一个具有以下内容的redirect.conf文件:

server {
  listen        80;

  server_name   _;

  return 301 https://$host$request_uri;
}

Now just make sure that it appears in your sites-enabled folder, and when you’ve reloaded the Nginx process in the container, all requests to port 80 will be redirected to port 443 (HTTPS).

现在,只需确保它出现在sites-enabled文件夹中,然后在容器中重新加载Nginx进程后,对端口80的所有请求都将重定向到端口443(HTTPS)。

最后的想法 (Final Thoughts)

Now that your site is up and running, you can head over to SSL Labs and run a test to see how secure your site is. At the time of writing this, you should get a perfect score. However there is a big thing to notice about that.

现在您的站点已启动并正在运行,您可以转到SSL Labs并运行测试以查看站点的安全性。 在撰写本文时,您应该获得满分。 但是,有一件大事要注意。

There will always be a balance between security and convenience. In this case the weights are heavily on the side of security. If you run the test on SSL Labs and scroll down, you will see there are multiple devices that won’t be able to connect with your site, because they don’t support new standards.

在安全性和便利性之间始终将保持平衡。 在这种情况下,权重很大程度上取决于安全性。 如果您在SSL实验室上运行测试并向下滚动,则会看到有多个设备无法连接到您的站点,因为它们不支持新标准。

So have this in mind when you are setting this up. Right now I am just running a server at home, where I don’t have to worry about that many people being able to access it. But if you do a scan on Facebook, you’ll see they won’t have as great a score, however their site can be accessed by more devices.

因此,在进行设置时请牢记这一点。 现在,我只是在家中运行一台服务器,而不必担心有那么多人可以访问它。 但是,如果您在Facebook上进行扫描,您会发现他们的得分不会很高,但是可以通过更多设备访问他们的网站。

翻译自: https://www.freecodecamp.org/news/docker-nginx-letsencrypt-easy-secure-reverse-proxy-40165ba3aee2/

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值