CN112637346B

CN112637346B - 代理方法、装置、代理服务器及存储介质

Info

Publication number: CN112637346B
Application number: CN202011553524.5A
Authority: CN
Inventors: 廖志伟
Original assignee: Beijing Knownsec Information Technology Co Ltd
Current assignee: Beijing Knownsec Information Technology Co Ltd
Priority date: 2020-12-24
Filing date: 2020-12-24
Publication date: 2023-12-01
Anticipated expiration: 2040-12-24
Also published as: CN112637346A

Abstract

本申请实施例涉及通信技术领域，提供一种代理方法、装置、代理服务器及存储介质，当接收到客户端发送的访问请求时，代理服务器获取该访问请求携带的目标域名，并根据预存的域名与IP地址的对应关系，获得目标域名对应的目标IP地址；之后，将访问请求转发给目标IP地址对应的目标业务服务器，以使目标业务服务器响应访问请求返回请求结果；再由代理服务器将请求结果反馈至客户端。也就是，代理服务器只需维护域名和IP地址的对应关系，这样当需要增加服务时，只需要添加相应的域名和IP地址的对应关系即可，部署简单且成本低，实用性强。

Description

代理方法、装置、代理服务器及存储介质

技术领域

本申请实施例涉及通信技术领域，具体而言，涉及一种代理方法、装置、代理服务器及存储介质。

背景技术

反向代理是一种接收Internet上客户端的访问请求，然后将访问请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给客户端的一种方式。

现有的反向代理方式主要有两种：一是采用Nginx实现反向代理，由于服务实例的配置经常变化，故需要投入人力修改Nginx配置，大大增加了大量配置文件的管理维护工作量；二是通过第三方服务注册表(例如Etcd、Consul、Zookeeper等)进行服务注册，这种方式部署成本较高。

因此，现有的反向代理方式，存在部署成本高，且每增加一组服务就需要重新修改配置或者重新部署代理服务的问题。

发明内容

本申请实施例的目的在于提供一种代理方法、装置、代理服务器及存储介质，用以改善上述问题。

为了实现上述目的，本申请实施例采用的技术方案如下：

第一方面，本申请实施例提供了一种代理方法，应用于代理服务器，所述代理服务器与客户端通信连接，且与至少一个业务服务器通信连接，所述方法包括：

接收客户端发送的访问请求，并获取所述访问请求携带的目标域名；

根据预存的域名与IP地址的对应关系，获得所述目标域名对应的目标IP地址；

将所述访问请求转发至所述目标IP地址对应的目标业务服务器；

接收所述目标业务服务器响应所述访问请求返回的请求结果，并将所述请求结果发送至所述客户端。

可选地，所述根据预存的域名与IP地址的对应关系，获得所述目标域名对应的目标IP地址的步骤，包括：

将所述目标域名与预存的各个域名一一进行比对；

若存在一个域名与所述目标域名相同，则获取该域名对应的IP地址作为所述目标IP地址。

可选地，所述域名与IP地址的对应关系是通过以下方式得到的：

所述代理服务器生成凭证，将所述凭证下发至所述业务服务器；

所述业务服务器对所述凭证进行验证，并在验证成功后获得IP地址，其中，所述业务服务器的IP地址和所述代理服务器的IP地址同网段；

所述业务服务器访问域名服务器生成域名，以及将所述域名解析到所述代理服务器的IP地址；

所述业务服务器创建所述域名与IP地址的对应关系。

可选地，所述凭证为加密后的配置文件；所述业务服务器对所述凭证进行验证，并在验证成功后获得IP地址，包括：

所述业务服务器对所述凭证进行解密，得到所述配置文件；

所述业务服务器运行所述配置文件，以连接所述代理服务器；

若所述业务服务器连接所述代理服务器成功，则所述凭证验证成功，所述代理服务器为所述业务服务器分配IP地址。

可选地，所述代理服务器为OpenResty服务器，所述域名与IP地址的对应关系存储于Redis数据库；

所述根据预存的域名与IP地址的对应关系，获得所述目标域名对应的目标IP地址的步骤，包括：

所述OpenResty服务器通过Lua脚本获取所述Redis数据库中存储的所述域名与IP地址的对应关系；

所述OpenResty服务器从所述域名与IP地址的对应关系中，确定出所述目标域名对应的目标IP地址。

第二方面，本申请实施例还提供了一种代理装置，应用于代理服务器，所述代理服务器与客户端通信连接，且与至少一个业务服务器通信连接，所述装置包括：

接收模块，用于接收客户端发送的访问请求，并获取所述访问请求携带的目标域名；

第一执行模块，用于根据预存的域名与IP地址的对应关系，获得所述目标域名对应的目标IP地址；

发送模块，用于将所述访问请求转发至所述目标IP地址对应的目标业务服务器；

第二执行模块，用于接收所述目标业务服务器响应所述访问请求返回的请求结果，并将所述请求结果发送至所述客户端。

可选地，所述第一执行模块具体用于：

将所述目标域名与预存的各个域名一一进行比对；

所述第一执行模块具体用于：

第三方面，本申请实施例还提供了一种代理服务器，所述代理服务器包括：一个或多个处理器；存储器，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现上述的代理方法。

第四方面，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述的代理方法。

相对现有技术，本申请实施例提供的一种代理方法、装置、代理服务器及存储介质，当接收到客户端发送的访问请求时，代理服务器获取该访问请求携带的目标域名，并根据预存的域名与IP地址的对应关系，获得目标域名对应的目标IP地址；之后，将访问请求转发给目标IP地址对应的目标业务服务器，以使目标业务服务器响应访问请求返回请求结果；再由代理服务器将请求结果反馈至客户端。也就是，代理服务器只需维护域名和IP地址的对应关系，这样当需要增加服务时，只需要添加相应的域名和IP地址的对应关系即可，部署简单且成本低，实用性强。

附图说明

图1示出了Nginx反向代理的应用场景示意图。

图2示出了Nginx反向代理的示例图。

图3示出了使用Zookeeper反向代理的示例图。

图4示出了本申请实施例提供的代理方法的应用场景示意图。

图5示出了本申请实施例提供的代理方法的流程示意图。

图6示出了本申请实施例提供的得到域名与IP地址的对应关系的场景示意图。

图7示出了本申请实施例提供的得到域名与IP地址的对应关系的流程示意图。

图8示出了本申请实施例提供的代理装置的方框示意图。

图9示出了本申请实施例提供的代理服务器的方框示意图。

图标：10-代理服务器；20-客户端；30-业务服务器；40-域名服务器；11-处理器；12-存储器；13-总线；100-代理装置；110-接收模块；120-第一执行模块；130-发送模块；140-第二执行模块。

具体实施方式

下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述。

代理服务包括正向代理和反向代理，正向代理是将来自内网客户端的请求转发到外网服务器，反向代理是将来自外网客户端的请求转发到内网服务器。

在实际应用中，可能会存在一类服务，既需要部署在自建机房的服务器上，有需要避免被溯源，因此，针对这类服务，可以通过代理服务器进行反向代理，从而在隐藏真实IP地址的情况下继续提供服务。

现有的反向代理方式主要有两种：

一是采用Nginx实现反向代理。Nginx是一款轻量级的Web服务器、反向代理服务器，由于它的内存占用少、启动极快、高并发能力强，故广泛应用在互联网项目中。

例如，请参照图1，Nginx服务器负责转发用户请求到指定的服务器，Nginx服务器通常是以配置文件为转发规则进行转发。WebServer A和WebServer B为业务服务器，WebServer C的2台服务器提供相同的业务，即服务器组。Nginx服务器可以通过修改配置文件来改变转发规则，弹性的扩展业务服务器的数量。

也就是，Nginx服务器对用户请求进行处理时，存在多少个需要代理的域名，就需要生成多少个配置文件，且当用户希望通过别的域名访问后台程序时，Nginx代理配置中将增加一新域名，此时需要生成相应的配置文件，这样就会造成配置文件越来越多，大大增加了大量配置文件的管理维护工作量。

二是通过第三方服务注册表(例如Etcd、Consul、Zookeeper等)进行服务注册。

以Zookeeper为例，请参照图2，常规的Nginx反向代理是客户端向Nginx服务器发送访问请求，Nginx服务器根据配置文件，将该访问请求转发到指定服务器，如果集群中的节点挂掉了，Nginx服务器并不能很快的至少，这样如果继续分配访问请求，就会出问题。

基于此，可以使用zookeeper进行反向代理，请参照图3，当服务器启动时，会在Zookeeper的Servers节点下创建一个短暂节点来存储服务器的信息，客户端只需要读取Servers节点下的子节点就可以获取到服务器的地址信息；当有服务器下线后，对应的Servers节点下的短暂节点会被删除，客户端通过Servers节点就能获知哪个服务器下线，从而及时将访问列表中的对应服务器信息删除。

因此，与采用Nginx实现反向代理的方式相比，这种方式可以减少人力，但是，有一定的开发成本，并且部署或迁移相对复杂，依赖项较多，并且相对于采用Nginx的方式，有太多的冗余功能。

为了解决上述问题，本申请实施例提供一种代理方法，代理服务器维护有域名和IP地址的对应关系，在接收到客户端的访问请求后，通过提取访问请求中携带的目标域名，并根据域名和IP地址的对应关系，确定出目标域名对应的目标IP地址，再将访问请求转发到目标IP地址对应的业务服务器，从而实现反向代理。与现有的反向代理方式相比，本申请实施例中代理服务器只需维护域名和IP地址的对应关系，并且当需要增加服务时，只需要添加相应的域名和IP地址的对应关系即可，部署简单且成本低，实用性强。

需要指出的是，本申请实施例中的业务服务器可以是机房服务器，通过上述反向代理的方式，可以将机房服务器上部署的服务暴露到互联网，并且可以在隐藏真实IP地址的情况下提供服务，同时能够避免被网络溯源。

请参照图4，图4示出了本申请实施例提供的代理方法的应用场景示意图，包括代理服务器10、客户端20及至少一个业务服务器30，客户端20与代理服务器10通信连接，代理服务器10与至少一个业务服务器30均通信连接。

客户端20可以是任何具有上网功能的移动终端，例如，智能手机、笔记本电脑、平板电脑、台式计算机、智能电视等。

客户端20可以向代理服务器10发送访问请求，代理服务器10在接收到客户端20发送的访问请求后，可以提取访问请求中的目标域名，即，客户端20想要访问的域名。代理服务器10从访问请求中提取出目标域名之后，可以从数据库中读取预存的域名与IP地址之间的对应关系，再根据域名与IP地址之间的对应关系，确定出目标域名对应的目标IP地址。之后，代理服务器10将访问请求转发至目标IP地址对应的业务服务器30，业务服务器30响应访问请求产生请求结果，并将请求结果返回至业务服务器30。最后，业务服务器30将请求结果返回至客户端20。

代理服务器10可以是OpenResty服务器，OpenResty服务器通过汇聚各种设计精良的Nginx服务器，从而将Nginx服务器有效地变成一个强大的通用Web应用平台。这样，Web开发人员和系统工程师可以使用Lua语言调动Nginx，Nginx支持各种C及Lua模块，能够快速构造出10K甚至1000K以上单机并发连接的高性能Web系统。

可以理解为，OpenResty服务器是Nginx服务器的强化版，能使用Lua语言编写脚本调用大量精良的Lua库、第三方模块以及大多数的依赖项。

数据库可以是Redis数据库，也可以是其他的存储类型服务。Redis是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，本实施例对Redis数据库组成结构不做详述。

数据库(例如，Redis)可以安装在代理服务器10上，也可以安装在其他服务器上。如果数据库(例如，Redis)安装在其他服务器上，则需要保证代理服务器10可以访问到数据库(例如，Redis)。

数据库(例如，Redis)可以用来存储域名与IP地址的对应关系，也就是说，将用户可以使用的各个域名、以及各个业务服务器30的IP地址，预先存储至数据库中，这些域名和IP地址之间存在一定的对应关系，即，域名与IP地址的对应关系。该对应关系的表现方式可以是对应关系表，也可以是其他方式，在此不做限定。

OpenResty服务器可以使用Lua脚本读取数据库(例如，Redis)中存储的数据，即，域名与IP地址的对应关系。

下面对本申请实施例提供的代理方法进行详细介绍。

在图4所示的应用场景示意图的基础上，请参照图5，图5示出了本申请实施例提供的代理方法的一种流程示意图，该代理方法应用于代理服务器10，可以包括以下步骤：

S101，接收客户端发送的访问请求，并获取访问请求携带的目标域名。

S102，根据预存的域名与IP地址的对应关系，获得目标域名对应的目标IP地址。

S103，将访问请求转发至目标IP地址对应的目标业务服务器。

S104，接收目标业务服务器响应访问请求返回的请求结果，并将请求结果发送至客户端。

客户端20发送至代理服务器10的访问请求中，通常携带有目标域名，即，用户想要访问的业务服务器30的域名，例如，http://host/a/。代理服务器10在接收到该访问请求后，可以提取该访问请求中携带的目标域名。

之后，代理服务器10从数据库(例如，Redis)中读取域名与IP地址的对应关系，再根据域名与IP地址的对应关系，确定出目标域名对应的目标IP地址。一个域名可以指向一个IP地址，对应一个业务服务器30；一个域名也可以指向多个IP地址，对应多个业务服务器30，即，服务器组。例如，域名与IP地址的对应关系表如下表1所示，假设目标域名为http://host/a/，则可以确定出目标IP地址为192.168.0.1:8080。

表1域名与IP地址的对应关系表

之后，代理服务器10将访问请求转发至目标IP地址(例如，192.168.0.1:8080)对应的目标业务服务器。如果确定出的目标IP地址有一个，则直接将访问请求转发给该目标IP地址对应的目标业务服务器；如果确定出的目标IP地址有多个，则从多个目标IP地址中选一个，并将访问请求转发给选定的目标IP地址对应的目标业务服务器。

之后，目标业务服务器响应访问请求，并返回请求内容至代理服务器10，再由代理服务器10返回给客户端20。

需要指出的是，如果代理服务器10与目标业务服务器之间的网络正常，则代理服务器10返回的请求内容就是用户想要的内容；如果代理服务器10与目标业务服务器之间的网络异常，则代理服务器10返回的请求内容就是一个错误页面。

作为一种实施方式，步骤S102可以包括以下子步骤：

S1021，将目标域名与预存的各个域名一一进行比对。

S1022，若存在一个域名与目标域名相同，则获取该域名对应的IP地址作为目标IP地址。

作为另一种实施方式，当代理服务器10为OpenResty服务器，域名与IP地址的对应关系存储于Redis数据库时，步骤S102可以包括以下子步骤：

S102a，OpenResty服务器通过Lua脚本获取Redis数据库中存储的域名与IP地址的对应关系。

S102b，OpenResty服务器从域名与IP地址的对应关系中，确定出目标域名对应的目标IP地址。

根据以上内容可知，本实施例中，代理服务器10只需维护域名与IP地址的对应关系，这样当需要增加服务时，只需要添加相应的域名和IP地址的对应关系即可，部署简单且成本低，实用性强。

下面以任意一个业务服务器30为例，对得到域名与IP地址的对应关系的过程进行详细介绍。

请参照图6，管理员上传凭证至业务服务器30，凭证可以是由管理员定义的一种规则，只要规则通过就可以打通代理服务器10与业务服务器30之间的网络。

业务服务器30接收到凭证之后，对该凭证进行验证。凭证可以是加密后的配置文件，业务服务器30对凭证进行验证的过程可以是：先对凭证进行解密得到配置文件，然后运行这个配置文件连接代理服务器10，如果连接到代理服务器10，则说明凭证验证成功，代理服务器10为业务服务器30分配IP地址，业务服务器30的IP地址和业务服务器30同网段。

业务服务器30获得代理服务器10为其分配的IP地址后，访问域名服务器40注册域名。一般来说，域名提供商都会提供API接口，因此，业务服务器30通过调用域名服务器40的API接口，就可以注册域名。

在域名注册过程中，业务服务器30首先调用域名服务器40的API接口，随机生成一个域名，例如，xxxx.abc.com；然后，创建业务服务器30的域名与IP地址的对应关系，并查询数据库中是否存在该对应关系；如果数据库中不存在该对应关系，则完成域名注册；如果数据库中存在该对应关系，则再重新随机生成一个域名，直至数据库中不存在该对应关系，完成域名注册。

需要指出的是，如果数据库(例如，Redis)安装在其他服务器上，则不仅要保证代理服务器10可以访问到数据库(例如，Redis)，还要保证业务服务器30也可以访问到数据库(例如，Redis)。

业务服务器30完成域名注册后，还需要访问域名服务器40将域名解析到代理服务器10的IP地址，即，业务服务器30调用域名服务器40的API接口，将域名解析到代理服务器10的IP地址，便于后续客户端20访问时，可以由域名服务器40实现域名到代理服务器10的IP地址的解析，使得客户端20可以将访问请求发送至代理服务器10。

最后，业务服务器30将其域名与IP地址的对应关系存储到数据库(例如，Redis)。

在图6所示的场景示意图的基础上，请参照图7，得到域名与IP地址的对应关系的过程，可以包括以下步骤：

S201，代理服务器生成凭证，将凭证下发至业务服务器。

S202，业务服务器对凭证进行验证，并在验证成功后获得IP地址，其中，业务服务器的IP地址和代理服务器的IP地址同网段。

S203，业务服务器访问域名服务器生成域名，以及将域名解析到代理服务器的IP地址。

S204，业务服务器创建域名与IP地址的对应关系。

以OpenVPN的方式为例，代理服务器10为OpenVPN服务端，业务服务器30为OpenVPN客户端。OpenVPN服务端生成一个配置文件，加密后的配置文件作为凭证上传至业务服务器30。

代理服务器10作为OpenVPN服务端，默认配置IP地址为10.1.0.1；OpenVPN服务端生成OpenVPN配置文件，并对该OpenVPN配置文件进行加密得到凭证，再将该凭证发送给业务服务器30，即，OpenVPN客户端；OpenVPN客户端先对该凭证进行解密得到OpenVPN配置文件，之后OpenVPN客户端运行OpenVPN配置文件连接OpenVPN服务端；如果OpenVPN客户端连接到OpenVPN服务端，则OpenVPN服务端会为OpenVPN客户端分配一个同网段的IP地址，例如，10.1.0.2，此时OpenVPN客户端和OpenVPN服务端之间的网络被打通。

业务服务器30上可以部署Web Server，且Web Server包括注册域名、以及保存域名与IP地址的对应关系的逻辑。

业务服务器30获得代理服务器10为其分配的IP地址后，调用域名服务器40的API接口生成域名，以及将该域名解析到代理服务器10的IP地址，以使域名服务器40将该域名与代理服务器10的IP地址关联。最后，业务服务器30将域名与IP地址的对应关系存储到数据库(例如，Redis)。

在图7的基础上，步骤S202可以包括以下子步骤：

S2021，业务服务器对凭证进行解密，得到配置文件。

S2022，业务服务器运行配置文件，以连接代理服务器。

S2023，若业务服务器连接代理服务器成功，则凭证验证成功，代理服务器为业务服务器分配IP地址。

也就是，业务服务器30对凭证进行解密，得到配置文件；之后，业务服务器30运行配置文件，如果能连接到代理服务器10，则表明凭证验证成功，此时代理服务器10会为业务服务器30分配一个同网段的IP地址。如果业务服务器30对凭证解密失败，或者，业务服务器30运行配置文件无法连接到代理服务器10，都表明凭证验证失败。

本申请实施例提供的代理方法具有以下有益效果：

首先，现有的反向代理方式，需要为业务服务器30分配外网IP地址，再将域名解析到该外网IP地址，才能通过域名访问到业务服务器30。本申请实施例提供的代理方法，不需要为业务服务器30分配外网IP地址，只需代理服务器10有外网IP地址，业务服务器30只有内网IP地址，从而可以为机房服务器提供反溯源代理，即使不分配外网端口也能对外提供服务。

其次，现有的反向代理方式，如果要新增服务，则需要修改配置文件，并且需要重新反向代理服务，会造成运行中的服务中断，并且，随着服务的增加，配置文件会越来越多，出错几率随之增加，并且需要大量人力进行管理维护。本申请实施例提供的代理方法，如果需要增加服务，则只需要添加相应的域名和IP地址的对应关系即可，部署简单且成本低，并且业务服务器30的域名和IP地址可以动态配置，易于服务的横向扩展、发布和下线。

第三，生成域名和IP地址的动作由业务服务器30完成，减少了人工配置的次数，减少了出错的几率，配置文件只需配置成有访问请求，提取访问请求中的域名去确定对应的IP地址，再将请求转发到该IP地址对应的业务服务器30即可。因此，站在开发者的角度，本申请实施例提供的代理方法部署更加方便，学习成本较低，减少了开发者的工作量，同时大幅度减少了配置文件的内容和修改次数，使服务运行更加稳定。

第四，本申请实施例不需要维护配置文件，只需维护域名和IP地址的对应关系，因此，站在项目角度，本申请实施例提供的代理方法，项目维护成本低，且迁移成本低。

请参照图8，图8示出了本申请实施例提供的代理装置100的方框示意图。代理装置100包括：接收模块110、第一执行模块120、发送模块130及第二执行模块140。

接收模块110，用于接收客户端发送的访问请求，并获取访问请求携带的目标域名。

第一执行模块120，用于根据预存的域名与IP地址的对应关系，获得目标域名对应的目标IP地址。

发送模块130，用于将访问请求转发至目标IP地址对应的目标业务服务器。

第二执行模块140，用于接收目标业务服务器响应访问请求返回的请求结果，并将请求结果发送至客户端。

可选地，第一执行模块120具体用于：将目标域名与预存的各个域名一一进行比对；若存在一个域名与目标域名相同，则获取该域名对应的IP地址作为目标IP地址。

可选地，代理服务器10为OpenResty服务器，域名与IP地址的对应关系存储于Redis数据库；

第一执行模块120具体用于：OpenResty服务器通过Lua脚本获取Redis数据库中存储的域名与IP地址的对应关系；OpenResty服务器从域名与IP地址的对应关系中，确定出目标域名对应的目标IP地址。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的代理装置100的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

请参照图9，图9示出了本申请实施例提供的代理服务器10的方框示意图。代理服务器10包括处理器11、存储器12及总线13，处理器11通过总线13与存储器12连接。

存储器12用于存储程序，例如图8所示的代理装置100。代理装置100包括至少一个可以软件或固件(firmware)的形式存储于存储器12中的软件功能模块，处理器11在接收到执行指令后，执行所述程序以实现上述实施例揭示的代理方法。

存储器12可能包括高速随机存取存储器(Random Access Memory，RAM)，也可能还包括非易失存储器(non-volatile memory，NVM)。

处理器11可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器11中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器11可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、微控制单元(Microcontroller Unit，MCU)、复杂可编程逻辑器件(Complex Programmable LogicDevice，CPLD)、现场可编程门阵列(Field Programmable Gate Array，FPGA)、嵌入式ARM等芯片。

本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器11执行时实现上述实施例揭示的代理方法。

综上所述，本申请实施例提供的一种代理方法、装置、代理服务器及存储介质，当接收到客户端发送的访问请求时，代理服务器获取该访问请求携带的目标域名，并根据预存的域名与IP地址的对应关系，获得目标域名对应的目标IP地址；之后，将访问请求转发给目标IP地址对应的目标业务服务器，以使目标业务服务器响应访问请求返回请求结果；再由代理服务器将请求结果反馈至客户端。也就是，代理服务器只需维护域名和IP地址的对应关系，这样当需要增加服务时，只需要添加相应的域名和IP地址的对应关系即可，部署简单且成本低，实用性强。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims

1.一种代理方法，其特征在于，应用于代理服务器，所述代理服务器与客户端通信连接，且与至少一个业务服务器通信连接，所述代理服务器分配有外网IP地址，所述业务服务器仅分配有内网IP地址，所述业务服务器为机房服务器，所述方法包括：

接收所述目标业务服务器响应所述访问请求返回的请求结果，并将所述请求结果发送至所述客户端；

所述域名与IP地址的对应关系是通过以下方式得到的：

所述业务服务器创建所述域名与IP地址的对应关系。

2.如权利要求1所述的方法，其特征在于，所述根据预存的域名与IP地址的对应关系，获得所述目标域名对应的目标IP地址的步骤，包括：

将所述目标域名与预存的各个域名一一进行比对；

3.如权利要求1所述的方法，其特征在于，所述凭证为加密后的配置文件；

所述业务服务器对所述凭证进行验证，并在验证成功后获得IP地址，包括：

所述业务服务器对所述凭证进行解密，得到所述配置文件；

4.如权利要求1所述的方法，其特征在于，所述代理服务器为OpenResty服务器，所述域名与IP地址的对应关系存储于Redis数据库；

5.一种代理装置，其特征在于，应用于代理服务器，所述代理服务器与客户端通信连接，且与至少一个业务服务器通信连接，所述代理服务器分配有外网IP地址，所述业务服务器仅分配有内网IP地址，所述业务服务器为机房服务器，所述装置包括：

第二执行模块，用于接收所述目标业务服务器响应所述访问请求返回的请求结果，并将所述请求结果发送至所述客户端；

所述域名与IP地址的对应关系是通过以下方式得到的：

所述业务服务器创建所述域名与IP地址的对应关系。

6.如权利要求5所述的装置，其特征在于，所述第一执行模块具体用于：

将所述目标域名与预存的各个域名一一进行比对；

7.如权利要求5所述的装置，其特征在于，所述代理服务器为OpenResty服务器，所述域名与IP地址的对应关系存储于Redis数据库；

所述第一执行模块具体用于：

8.一种代理服务器，其特征在于，所述代理服务器包括：

一个或多个处理器；

存储器，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1-4中任一项所述的代理方法。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现如权利要求1-4中任一项所述的代理方法。