nginx做反向代理，在自己的电脑用虚拟机安装一个服务器做后台，你说的是Linux的，可以是都是window系统吗

　　nginx 轻量级、高性能 web server 主要干两件事情：　〉直接作http server(代替apachePHP需要FastCGI处理器支持)；　〉另外功能作反向中国服务器实现负载均衡　我举例说明何使用 nginx 实现负载均衡nginx处理并发面优势现应用非见Apache mod_proxymod_cache结合使用实现台app server反向中国负载均衡并发处理面apache没 nginx擅　1)环境：　a 我本Windows系统使用VirutalBox安装虚拟Linux系统　本Windows系统别安装nginx(侦听8080端口)apache(侦听80端口)虚拟Linux系统安装apache(侦听80端口)　我相于拥1台nginx前端作反向中国服务器；面2台apache作应用程序服务器(看作型server cluster;-) )；　b nginx用作反向中国服务器放置两台apache前作用户访问入口；　nginx仅仅处理静态页面态页面(php请求)统统都交付给台两台apache处理　说我中国站静态页面或者文件放置nginx目录；态页面数据库访问都保留台apache服务器　c 介绍两种实现server cluster负载均衡　我假设前端nginx(127001:80)仅仅包含静态页面indexhtml；　台两apache服务器(别localhost:801583770143:80)台根目录放置phpMyAdmin文件夹testphp(面测试代码print server1;)另台根目录仅仅放置testphp(面测试代码 print server2;)　2)针同请求 负载均衡：　a 简单构建反向中国候 (nginx仅仅处理静态处理态内容态内容交给台apache server处理)我具体设置：nginxconf修改：　复制代码 代码:　location ~ \php$ {　proxy_pass 1583770143:80 ;　}　〉 客户端访问localhost:8080/indexhtml候前端nginx自进行响应；　〉用户访问localhost:8080/testphp候(候nginx目录根本没该文件)通面设置 location ~ \php$(表示则表达式匹配php结尾文件详情参看location何定义匹配 中国wikinginxorg/NginxHttpCoreModule) nginx服务器自pass给 1583770143apache服务器该服务器testphp自解析html结页面返给nginx nginx进行显示(nginx使用memcached模块或者squid支持缓存)输结打印server2　简单使用nginx做反向中国服务器例；　b 我现例进行扩展使其支持两台服务器　我设置nginxconfserver模块部应部修改：　复制代码 代码:　location ^~ /phpMyAdmin/ {　proxy_pass 127001:80 ;　}　location ~ \php$ {　proxy_pass 1583770143:80 ;　}　面第部location ^~ /phpMyAdmin/表示使用则表达式匹配(^~)直接匹配客户端访问 URL中国localhost:8080/phpMyAdmin/ (本nginx目录根本没phpMyAdmin目录)nginx自pass127001:80 Apache服务器该服务器phpMyAdmin目录页面进行解析结发送给nginx者显示；　客户端访问URL中国localhost/testphp 则pass1583770143:80 apache进行处理　综我实现针同请求负载均衡　〉用户访问静态页面indexhtml前端nginx直接进行响应；　〉用户访问testphp页面1583770143:80 Apache进行响应；　〉用户访问目录phpMyAdmin页面127001:80 Apache进行响应；　3)访问同页面 负载均衡：　即用户访问中国localhost:8080/testphp 同页面候我实现两台服务器负载均衡 (实际情况两服务器数据要求同步致我别定义打印server1server2进行辨认区别)　a 现我情况windowsnginxlocalhost侦听8080端口；　两台apache台127001:80(包含testphp页面打印server1)另台虚拟机1583770143:80(包含testphp页面打印server2)　b 重新配置nginxconf：　〉首先nginx配置文件nginxconfhttp模块添加服务器集群server cluster(我两台)定义：　复制代码 代码:　upstream myCluster {　server 127001:80 ;　server 1583770143:80 ;　}　表示server cluster包含2台服务器　〉server模块定义负载均衡：　复制代码 代码:　location ~ \php$ {　proxy_pass 中国myCluster ; #名字面cluster名字相同　proxy_redirect off;　proxy_set_header Host $host;　proxy_set_header X-Real-IP $remote_addr;　proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;　}　访问中国localhost:8080/testphp 页面nginx目录根本没该文件自其passmyCluster定义服务区机群别由127001:80;或者1583770143:80;做处理　面定义upstream候每server没定义权重表示两者均衡；希望某更响应例：　复制代码 代码:　upstream myCluster {　server 127001:80 weight=5;　server 1583770143:80 ;　}　表示5/6几率访问第server,1/6访问第二另外定义max_failsfail_timeout等参数　综我使用nginx反向中国服务器reverse proxy server功能其布置台apache server前端　nginx仅仅用处理静态页面响应态请求中国pass台apache server作app server前台pass态页面进行处理并返给nginx　通架构我实现nginx台apache构机群cluster负载均衡　两种均衡：　1)nginx定义访问同内容中国同台server； 例访问phpMyAdmin目录中国第台server；访问testphp中国第二台server；　2)nginx定义访问同页面均衡 (服务器性能同定义权重均衡)中国同台server 例访问testphp页面均衡中国server1或者server2　实际应用server1server2别保留相同app程序数据需要考虑两者数据同

了解着名的Nginx服务器（微服务必不可少的东西）如何用作API网关。

现代应用程序体系结构的核心是HTTP API。 HTTP使应用程序能够快速构建并轻松维护。无论应用程序的规模如何，HTTP API都提供了一个通用接口，从单用途微服务到无所不包的整体。通过使用HTTP，支持超大规模Internet属性的Web应用程序交付的进步也可用于提供可靠和高性能的API交付。

有关API网关对微服务应用程序重要性的精彩介绍，请参阅我们博客上的构建微服务：使用API​​网关。

作为领先的高性能，轻量级反向代理和负载均衡器，NGINX Plus具有处理API流量所需的高级HTTP处理功能。这使得NGINX Plus成为构建API网关的理想平台。在这篇博文中，我们描述了许多常见的API网关用例，并展示了如何配置NGINX Plus以便以高效，可扩展且易于维护的方式处理它们。我们描述了一个完整的配置，它可以构成生产部署的基础。

注意：除非另有说明，否则本文中的所有信息均适用于NGINX Plus和NGINX开源。

API网关的主要功能是为多个API提供单一，一致的入口点，无论它们在后端如何实现或部署。并非所有API都是微服务应用程序。我们的API网关需要管理现有的API，单块和正在部分过渡到微服务的应用程序。

在这篇博文中，我们引用了一个假设的库存管理API，即“仓库API”。我们使用示例配置代码来说明不同的用例。 Warehouse API是一个RESTful API，它使用JSON请求并生成JSON响应。但是，当部署为API网关时，使用JSON不是NGINX Plus的限制或要求; NGINX Plus与API本身使用的架构风格和数据格式无关。

Warehouse API实现为离散微服务的集合，并作为单个API发布。库存和定价资源作为单独的服务实施，并部署到不同的后端。所以API的路径结构是：

例如，要查询当前仓库库存，客户端应用程序会向/ api / warehouse / inventory发出HTTP GET请求。

使用NGINX Plus作为API网关的一个优点是，它可以执行该角色，同时充当现有HTTP流量的反向代理，负载平衡器和Web服务器。如果NGINX Plus已经是应用程序交付堆栈的一部分，那么通常不需要部署单独的API网关。但是，API网关所期望的某些默认行为与基于浏览器的流量的预期不同。出于这个原因，我们将API网关配置与基于浏览器的流量的任何现有（或未来）配置分开。

为实现这种分离，我们创建了一个支持多用途NGINX Plus实例的配置布局，并为通过CI / CD管道自动配置部署提供了便利的结构。 / etc / nginx下的结果目录结构如下所示。

所有API网关配置的目录和文件名都以api_为前缀。这些文件和目录中的每一个都启用API网关的不同特性和功能，并在下面详细说明。

所有NGINX配置都以主配置文件nginxconf开头。要读入API网关配置，我们在nginxconf的http块中添加一个指令，该指令引用包含网关配置的文件api_gatewayconf（下面的第28行）。请注意，默认的nginxconf文件使用include伪指令从confd子目录中引入基于浏览器的HTTP配置（第29行）。本博文广泛使用include指令来提高可读性并实现配置某些部分的自动化。

api_gatewayconf文件定义了将NGINX Plus公开为客户端的API网关的虚拟服务器。此配置公开API网关在单个入口点https://apiexamplecom/（第13行）发布的所有API，受第16到21行配置的TLS保护。请注意，此配置纯粹是HTTPS - 没有明文HTTP侦听器。我们希望API客户端知道正确的入口点并默认进行HTTPS连接。

此配置是静态的 - 各个API及其后端服务的详细信息在第24行的include伪指令引用的文件中指定。第27到30行处理日志记录默认值和错误处理，并在响应中讨论错误部分如下。

一些API可以在单个后端实现，但是出于弹性或负载平衡的原因，我们通常期望存在多个API。使用微服务API，我们为每个服务定义单独的后端;它们一起作为完整的API。在这里，我们的Warehouse API被部署为两个独立的服务，每个服务都有多个后端。

API网关发布的所有API的所有后端API服务都在api_backendsconf中定义。这里我们在每个块中使用多个IP地址 - 端口对来指示API代码的部署位置，但也可以使用主机名。 NGINX Plus订户还可以利用动态DNS负载平衡，自动将新后端添加到运行时配置中。

配置的这一部分首先定义Warehouse API的有效URI，然后定义用于处理对Warehouse API的请求的公共策略。

Warehouse API定义了许多块。 NGINX Plus具有高效灵活的系统，可将请求URI与配置的一部分进行匹配。通常，请求由最具体的路径前缀匹配，并且位置指令的顺序并不重要。这里，在第3行和第8行，我们定义了两个路径前缀。在每种情况下，$ upstream变量都设置为上游块的名称，该上游块分别代表库存和定价服务的后端API服务。

此配置的目标是将API定义与管理API交付方式的策略分开。为此，我们最小化了API定义部分中显示的配置。在为每个位置确定适当的上游组之后，我们停止处理并使用指令来查找API的策略（第10行）。

使用重写指令将处理移至API策略部分

重写指令的结果是NGINX Plus搜索匹配以/ _warehouse开头的URI的位置块。第15行的位置块使用=修饰符执行完全匹配，从而加快处理速度。

在这个阶段，我们的政策部分非常简单。位置块本身标记为第16行，这意味着客户端无法直接向它发出请求。重新定义$ api_name变量以匹配API的名称，以便它在日志文件中正确显示。最后，请求被代理到API定义部分中指定的上游组，使用$ request_uri变量 - 其中包含原始请求URI，未经修改。

API定义有两种方法 - 广泛而精确。每种API最合适的方法取决于API的安全要求以及后端服务是否需要处理无效的URI。

在warehouse_api_simpleconf中，我们通过在第3行和第8行定义URI前缀来使用Warehouse API的广泛方法。这意味着以任一前缀开头的任何URI都代理到相应的后端服务。使用基于前缀的位置匹配，对以下URI的API请求都是有效的：

如果唯一的考虑是将每个请求代理到正确的后端服务，则广泛的方法提供最快的处理和最紧凑的配置。另一方面，精确的方法使API网关能够通过显式定义每个可用API资源的URI路径来理解API的完整URI空间。采用精确的方法，Warehouse API的以下配置使用精确匹配（=）和正则表达式（〜）的组合来定义每个URI。

此配置更详细，但更准确地描述了后端服务实现的资源。这具有保护后端服务免于格式错误的客户端请求的优点，代价是正常表达式匹配的一些小额外开销。有了这个配置，NGINX Plus接受一些URI并拒绝其他URI无效：

使用精确的API定义，现有的API文档格式可以驱动API网关的配置。可以从OpenAPI规范（以前称为Swagger）自动化NGINX Plus API定义。此博客文章的Gists中提供了用于此目的的示例脚本。

随着API的发展，有时会发生需要更新客户端的重大更改。一个这样的示例是重命名或移动API资源。与Web浏览器不同，API网关无法向其客户端发送命名新位置的重定向（代码301）。幸运的是，当修改API客户端不切实际时，我们可以动态地重写客户端请求。

在下面的示例中，我们可以在第3行看到定价服务以前是作为库存服务的一部分实现的：rewrite指令将对旧定价资源的请求转换为新的定价服务。

动态重写URI意味着当我们最终在第26行代理请求时，我们不能再使用$ request_uri变量（正如我们在warehouse_api_simpleconf的第21行所做的那样）。这意味着我们需要在API定义部分的第9行和第14行使用稍微不同的重写指令，以便在处理切换到策略部分时保留URI。

HTTP API和基于浏览器的流量之间的主要区别之一是如何将错误传达给客户端。当NGINX Plus作为API网关部署时，我们将其配置为以最适合API客户端的方式返回错误。

顶级API网关配置包括一个定义如何处理错误响应的部分。

第27行的指令指定当请求与任何API定义都不匹配时，NGINX Plus会返回错误而不是默认错误。此（可选）行为要求API客户端仅向API文档中包含的有效URI发出请求，并防止未经授权的客户端发现通过API网关发布的API的URI结构。

第28行指的是后端服务本身产生的错误。未处理的异常可能包含我们不希望发送到客户端的堆栈跟踪或其他敏感数据。此配置通过向客户端发送标准化错误来进一步提供保护。

完整的错误响应列表在第29行的include伪指令引用的单独配置文件中定义，其前几行如下所示。如果首选不同的错误格式，并且通过更改第30行上的default_type值以匹配，则可以修改此文件。您还可以在每个API的策略部分中使用单独的include指令来定义一组覆盖默认值的错误响应。

有了这种配置，客户端对无效URI的请求就会收到以下响应。

在没有某种形式的身份验证的情况下发布API以保护它们是不常见的。 NGINX Plus提供了几种保护API和验证API客户端的方法。有关基于IP地址的访问控制列表（ACL），数字证书身份验证和HTTP基本身份验证的信息，请参阅文档。在这里，我们专注于API特定的身份验证方法。

API密钥身份验证

API密钥是客户端和API网关已知的共享密钥。它们本质上是作为长期凭证发布给API客户端的长而复杂的密码。创建API密钥很简单 - 只需编码一个随机数，如本例所示。

在顶级API网关配置文件api_gatewayconf的第6行，我们包含一个名为api_keysconf的文件，其中包含每个API客户端的API密钥，由客户端名称或其他描述标识。

API密钥在块中定义。 map指令有两个参数。第一个定义了API密钥的位置，在本例中是在$ http_apikey变量中捕获的客户端请求的apikey HTTP头。第二个参数创建一个新变量（$ api_client_name）并将其设置为第一个参数与键匹配的行上的第二个参数的值。

例如，当客户端提供API密钥7B5zIqmRGXmrJTFmKa99vcit时，$ api_client_name变量设置为client_one。此变量可用于检查经过身份验证的客户端，并包含在日志条目中以进行更详细的审核。

地图块的格式很简单，易于集成到自动化工作流程中，从现有的凭证存储生成api_keysconf文件。 API密钥身份验证由每个API的策略部分强制执行。

客户端应在apikey HTTP头中显示其API密钥。如果此标头丢失或为空（第20行），我们发送401响应以告知客户端需要进行身份验证。第23行处理API键与地图块中的任何键都不匹配的情况 - 在这种情况下，api_keysconf第2行的默认参数将$ api_client_name设置为空字符串 - 我们发送403响应告诉身份验证失败的客户端。

有了这个配置，Warehouse API现在可以实现API密钥身份验证。

JWT身份验证

JSON Web令牌（JWT）越来越多地用于API身份验证。原生JWT支持是NGINX Plus独有的，可以在我们的博客上验证JWT，如使用JWT和NGINX Plus验证API客户端中所述。

本系列的第一篇博客详细介绍了将NGINX Plus部署为API网关的完整解决方案。可以从我们的GitHub Gist仓库查看和下载此博客中讨论的完整文件集。本系列的下一篇博客将探讨更高级的用例，以保护后端服务免受恶意或行为不端的客户端的攻击。

原文：https://dzonecom/articles/deploying-nginx-plus-as-an-api-gateway-part-1-ngin

本文：http://pubintelligentxnet/deploying-nginx-plus-api-gateway-part-1-nginx

讨论：请加入知识星球或者小红圈首席架构师圈

就通过浏览器访问啊！如果是遇到问题，可能是以下原因：

1 检查网络

看win机ping linux机是否正常

2 检查端口

你开启的服务端口

比如你开了http，那就是80端口或者你自定义的端口，

3 检查防火墙

service iptables stop

你先测试一下是不是防火墙的原因，就关了看能否用，如果不行，说明是防火墙屏蔽掉了，可以设备防火墙放行对应端口，下面具体方法：

在虚拟机的Linux下安装好Nginx服务器后，本机可以通过curl获取网页内容，而在宿主机无法访问，出现如下错误：

打开文件/etc/sysconfig/iptables进行编辑，在ssh的默认端口22下面增加12行，用于nginx服务器，这里加多了13行端口3306，是为了mysql的远程访问。配置完后，重启防火墙即可。

service iptables restart

在宿主机再试试：

有时候硬件也要注意:   有关服务器，等算是“虚拟产品”的东西，我们要谨慎购买

虚拟机与服务器等，因为性能等方面都需要仔细看性能是否可以衔接！

如果还有什么问题的话，可以去咨询“小鸟云 "像他们这样的服务器厂商一定能给你解答！

配域名的时候，如果域名可以解析成多个ip，则通常使用轮询的方式访问

配置ip，访问就固定到那个ip上

如果域名只对应一个ip，则二者效果等效，但配置域名需要多一步域名解析的步骤

ip不变的情况下，配置成ip就可以了，如果ip会变，配置域名更好

1）

首先，你是什么系统？我想应该是linux，但也不排除是win的可能性

2）

你可以用建立一个软链接来实现

a盘：60g

/home/www

b盘：90g

/home2/www

具体怎么做，ln

-s

源文件

目标文件

3)

或者

你直接用abxxxcom定位到/home2/wwww下，就是在nginx下，在配置一个虚拟主机，主目录指向/home2/www