急求，5个代理服务器的IP码。

ID 地址 端口 类型 地区 验证时间 响应 WHOIS

1 212.12.185.70 8080 HTTP 沙特阿拉伯 ProxyCN 01-25 22:29 0.046 whois

2 219.83.5.118 3128 HTTP 印度尼西亚 ProxyCN 01-25 22:27 0.127 whois

3 195.128.166.146 3128 HTTP 欧洲 ProxyCN 01-25 22:18 0.497 whois

4 201.37.207.43 8080 HTTP 美国 中部/南部(IANA) 01-25 22:10 0.722 whois

5 200.233.185.219 3128 HTTP 巴西 圣保罗 01-25 22:12 0.776 whois

6 202.166.162.210 80 HTTP 巴基斯坦 ProxyCN 01-25 22:15 0.918 whois

7 202.146.225.85 80 HTTP 印度尼西亚 ProxyCN 01-25 22:03 0.932 whois

8 222.237.5.145 8080 HTTP 韩国 ProxyCN 01-25 22:15 0.973 whois

9 200.93.190.58 8080 HTTP 委内瑞拉 ProxyCN 01-25 22:14 0.978 whois

10 202.233.49.33 80 HTTP 日本 ProxyCN 01-25 22:08 0.979 whois

11 195.116.60.4 3128 HTTP 波兰 ProxyCN 01-25 22:33 0.980 whois

12 202.150.132.84 8080 HTTP 印度尼西亚 ProxyCN 01-25 22:19 0.981 whois

13 200.209.165.61 6588 HTTP 巴西 圣保罗 01-25 22:12 0.984 whois

14 200.142.177.62 6588 HTTP 巴西 圣保罗 01-25 22:14 0.986 whois

15 210.236.90.53 8080 HTTP 日本 ProxyCN 01-25 22:03 0.986 whois

16 213.61.120.101 80 HTTP 德国 ProxyCN 01-25 22:31 0.990 whois

17 202.145.10.87 8888 HTTP 印度尼西亚 ProxyCN 01-25 22:24 0.990 whois

18 211.9.159.121 80 HTTP 日本 ProxyCN 01-25 22:03 0.993 whois

19 210.251.180.55 80 HTTP 日本 ProxyCN 01-25 22:03 0.994 whois

20 60.28.196.37 80 HTTP 天津市 网通ADSL 01-25 22:14 0.995 whois

21 213.33.197.67 80 HTTP 俄罗斯 ProxyCN 01-25 22:31 0.996 whois

22 200.2.135.134 80 HTTP 巴西 圣保罗 01-25 22:15 0.996 whois

23 61.91.190.249 80 HTTP 泰国 ProxyCN 01-25 22:02 0.996 whois

24 212.121.235.58 3128 HTTP 西班牙 ProxyCN 01-25 22:31 0.998 whois

25 200.168.132.173 6588 HTTP 巴西 圣保罗 01-25 22:14 0.999 whois

26 211.100.19.7 8080 HTTP 北京市 ProxyCN 01-25 22:03 0.999 whois

27 211.233.41.135 80 HTTP 韩国 ProxyCN 01-25 22:03 0.999 whois

28 68.46.26.123 8080 HTTP 美国 Comcast有线网用户 01-25 22:29 1.000 whois

29 219.106.231.34 8080 HTTP 日本 东京 01-25 22:28 1.000 whois

30 70.66.18.201 80 HTTP 加拿大 ProxyCN 01-25 22:22 1.000 whois

31 195.20.3.236 8080 HTTP 英国 ProxyCN 01-25 22:18 1.000 whois

32 195.112.108.74 8080 HTTP 俄罗斯 ProxyCN 01-25 22:18 1.000 whois

33 61.19.144.104 80 HTTP 泰国 ProxyCN 01-25 22:26 1.001 whois

34 60.176.164.240 8080 HTTP 浙江省杭州市 电信ADSL 01-25 22:24 1.001 whois

35 69.79.227.46 6588 HTTP 美国 ProxyCN 01-25 22:22 1.001 whois

36 80.237.146.141 3128 HTTP 英国 德文郡 普里茅斯 01-25 22:21 1.001 whois

37 221.90.210.23 8080 HTTP 日本 ProxyCN 01-25 22:17 1.001 whois

38 201.53.109.243 6588 HTTP 美国 中部/南部(IANA) 01-25 22:10 1.001 whois

39 203.81.198.155 8080 HTTP 巴基斯坦 ProxyCN 01-25 22:08 1.001 whois

40 196.209.92.188 8080 HTTP 南非/加勒比 ProxyCN 01-25 22:17 1.002 whois

41 59.144.125.70 6588 HTTP 印度 BHARTI网络 01-25 22:27 1.003 whois

42 218.6.130.39 80 HTTP 四川省南充市 电信 01-25 22:22 1.003 whois

43 200.101.34.18 3128 HTTP 巴西 圣保罗 01-25 22:14 1.003 whois

44 201.7.250.122 3128 HTTP 巴西 圣保罗 01-25 22:11 1.004 whois

45 201.49.11.18 8080 HTTP 美国 中部/南部(IANA) 01-25 22:10 1.007 whois

46 61.232.61.43 8080 HTTP 江苏省苏州市 铁通 01-25 22:21 1.009 whois

47 172.187.135.200 6588 HTTP 美国 ProxyCN 01-25 22:18 1.009 whois

48 202.175.95.188 8080 HTTP 澳门 新桥区/新口岸 01-25 22:14 1.010 whois

49 218.133.132.16 8080 HTTP 日本 ProxyCN 01-25 22:28 1.054 whois

50 203.138.90.141 80 HTTP 日本 ProxyCN 01-25 22:08 1.859 whois

以下是最常见的顶级域：

com，用于商业组织。

edu，用于教育机构。

org，用于非赢利组织。

net，用于计算机网络组织。

gov，用于美国政府组织。

两字母或三字母国家/地区代码，如 jp 是日本的代码。

不同组织的域名在每个顶级域下面相应地分支展开。可以进一步沿树状结构细分出组织内各部门的更多域名（称为子域）。最后，将主机名加在名称结构的前面构成 FQDN，如“server2.msdn.microsoft.com”。事实上，“msdn.microsoft.com”也是一个 FQDN，它指的是 microsoft.com 中的某个 Web 服务器群集。

DNS 工作原理

DNS 是一个分布式数据库系统，它提供将域名转换成对应 IP 地址的信息。这种将名称转换成 IP 地址的方法称为名称解析。

一般来说，每个组织有其自己的 DNS 服务器，并维护域的名称映射数据库记录或资源记录。当请求名称解析时，DNS 服务器先在自己的记录中检查是否有对应的 IP 地址。如果未找到，它就会向其它 DNS 服务器询问该信息。

例如，当要求 Web 浏览器访问“msdn.microsoft.com”站点时，它就会通过以下步骤来解析该域名的 IP 地址：

Web 浏览器调用 DNS 客户端（称为解析器），并使用上次查询缓存的信息在本地解析该查询。

如果在本地无法解析查询，客户端就会向已知的 DNS 服务器询问答案。如果该 DNS 服务器曾经在特定的时间段内处理过相同的域名（“msdn.microsoft.com“）请求，它就会在缓存中检索相应的 IP 地址，并将它返回给客户端。

如果该 DNS 服务器找不到相应的地址，客户端就会向某个全局根 DNS 服务器询问，后者返回顶级域权威 DNS 服务器的指针。在这种情况下，“com”域权威服务器的 IP 地址将返回给客户端。

类似地，客户端向“com”服务器询问“microsoft.com”服务器的地址。然后，客户端将原始查询传到“microsoft.com”服务器。

因为“microsoft.com”服务器在本地维护“msdn.microsoft.com”域的权威记录，所以它将最终结果返回给客户端，并完成特定 IP 地址的查询。

注意，可以将 DNS 资源记录缓存到网络上任意数量的 DNS 服务器中。第 2 步中提到的 DNS 服务器可能不包含“msdn.microsoft.com”缓存记录。但是，它可能有“microsoft.com”的记录，更可能有“com”域的记录。这可省去客户端获得最终结果所需的一次或几次查询，从而加快了整个搜索过程。

为了维护 DNS 缓存中的最新信息，缓存记录有一个与信息关联的“生存时间”设置（类似于牛奶的保鲜期）。当记录到期时，必须对它们再次进行搜索。

DNS 资源记录

如前所述，每个 DNS 数据库都由资源记录构成。一般来说，资源记录包含与特定主机有关的信息，如 IP 地址、主机的所有者或者提供服务的类型。

资源记录类型

说明

解释

SOA

起始授权机构

此记录指定区域的起点。它所包含的信息有区域名、区域管理员电子邮件地址，以及指示辅 DNS 服务器如何更新区域数据文件的设置等。

常用的资源记录类型

A 地址 此记录列出特定主机名的 IP 地址。这是名称解析的重要记录。

CNAME 标准名称 此记录指定标准主机名的别名。

MX 邮件交换器 此记录列出了负责接收发到域中的电子邮件的主机。

NS 名称服务器 此记录指定负责给定区域的名称服务器。

DNS 区域

通常，DNS 数据库可分成不同的相关资源记录集。其中的每个记录集称为区域。区域可以包含整个域、部分域或只是一个或几个子域的资源记录。

管理某个区域（或记录集）的 DNS 服务器称为该区域的权威名称服务器。每个名称服务器可以是一个或多个区域的权威名称服务器。

在域中划分多个区域的主要目的是为了简化 DNS 的管理任务，即委派一组权威名称服务器来管理每个区域。采用这样的分布式结构，当域名称空间不断扩展时，各个域的管理员可以有效地管理各自的子域。

有时，区域和域是很难分辨的。

区域是域的子集。可以将它看作域名称空间的某个分支（或子树）。例如，Microsoft 名称服务器可以同时是“microsoft.com”区域、“msdn.microsoft.com”区域和“marketing.microsoft.com”区域的权威名称服务器。但是，可以将子域的区域（如“msdn.microsoft.com”）委派给其它专用名称服务器管理。如果设置的区域包含整个域的资源记录，那么该区域与该域的范围是相同的。

对于 Windows 2000，区域信息或者以传统文本文件格式存储，或者集成到 Active Directory 数据库中。稍后，我们将详细阐述 DNS 与 Active Directory 如何协作。

主 DNS 服务器和辅 DNS 服务器

为保证服务的高可用性，DNS 要求使用多台名称服务器冗余支持每个区域。

某个区域的资源记录通过手动或自动方式更新到单个主名称服务器（称为主 DNS 服务器）上。主 DNS 服务器可以是一个或几个区域的权威名称服务器。

其它冗余名称服务器（称为辅 DNS 服务器）用作同一区域中主服务器的备份服务器，以防主服务器无法访问或宕机。辅 DNS 服务器定期与主 DNS 服务器通讯，确保它的区域信息保持最新。如果不是最新信息，辅 DNS 服务器就会从主服务器获取最新区域数据文件的副本。这种将区域文件复制到多台名称服务器的过程称为区域复制。

Active Directory 和 DNS 的关系

Active Directory 是 Windows 2000 中新增的目录服务。该服务存储所有网络资源的信息，如计算机、共享文件夹、用户等等。它还通过标准的 Internet 协议（轻量目录访问协议，LDAP）将此类信息提供给用户和应用程序。有关 Active Directory 的详细信息，请参阅 Technet 文章设置 Active Directory 域 。

与 Microsoft Windows NT® 4.0 中的域控制器相比，Active Directory 与 DNS 的关系更加密切。实际上，DNS 是支持 Active Directory 所必需的。通常，安装 Active Directory 服务器时，如果网络上找不到 DNS 服务器，就会在安装过程中安装 DNS 服务器。

支持域控制器的定位器服务

Windows 2000 中最重要的新概念之一就是：计算机不再主要用网络基本输入/输出系统 (NetBIOS) 名称来标识，而是使用 DNS 完全合格的域名称 (FQDN) 来标识，如“server1.duwamishonline.com”。

因此，要登录并访问 Windows NT 域中的资源，Windows 2000 计算机必须查找 DNS 服务器，后者帮助定位 Active Directory 域控制器。换句话说，DNS 用作域控制器的定位器服务。

与 Active Directory 集成

Windows 2000 DNS 服务器的另一个重要功能是：DNS 区域可以集成到 Active Directory 中，以提供增强的容错和安全功能。每个与 Active Directory 集成的区域将自动复制到 Active Directory 域的所有域控制器中。

不过，仍可以将 Windows 2000 DNS 服务器配置为基于传统文件的 DNS 服务器。但是，要提供 DNS 服务容错功能，除主 DNS 服务器外，还必须手动安装辅 DNS 服务器。

配置 Duwamish Online 的 DNS 服务

Duwamish Online 要求使用外部和内部域名称解析。

在外部，DNS 服务将“[url]www.DuwamishOnline.com[/url]”解析为 Web 服务器的 IP 地址。Duwamish Online 应用程序使用内部名称解析来解析服务器的名称。要从 COM+ 列队组件 (QC) 访问消息队列 (MSMQ) 公共队列，必须使用 Active Directory，而后者又要求使用 DNS。有关 MSMQ 和网络体系结构的详细信息，请参阅 Duwamish Online Message Queuing Configuration 上的文章 。

在 Windows 2000 中安装 DNS 服务相对比较简单。但是，外部和内部 DNS 信息的安全要求是不同的。在本节中，我们将讨论这些安全问题和可能的解决方案。我们将讨论（消息队列配置使用的）Active Directory 服务与 Duwamish Online Web 群中 DNS 之间的关系。还要告诉您如何注册域名，如何安装带有 Windows 2000 的 DNS 服务器。

公用和专用 DNS 信息的安全问题

最初，我们安装了两台 DNS 服务器：一台主 DNS 服务器和一台用于冗余的辅 DNS 服务器。在这些 DNS 服务器中设置了两个区域：一个用于外部 Internet 域“DuwamishOnline.com”，另一个用于内部域“InternalDomain.com”。

如前所述，安装用于内部域的 DNS 服务器是 Windows 2000 Active Directory 域的新要求。使用该原始配置，将 DNS 服务器同时设置为内部域和外部域的“多主”，例如，外部网络接口卡 (NIC) 的 IP 地址为 192.168.100.1，内部 NIC 的 IP 地址为 10.10.10.1。

允许 Internet 用户向服务器查询外部区域。但是，因为同一 DNS 服务器同时管理外部和内部区域，所以外部用户也可以向服务器查询内部区域。Internet 用户可以使用基本网络工具（如名称服务搜索，NSLookup）访问所有内部域 DNS 信息。

理论上，无法将任何网络数据包路由到内部域，直接攻击内部服务器。但是，向外界泄露的内部信息越少，操作的安全性越高。这可防止他人利用后端服务器（此处存储重要业务信息）的潜在漏洞，进一步窃取机密信息。

一般直接用ps4拨号就是类型1，先连接路由器，再连ps4就是类型2。

首先NAT类型一般指的是网络状态类型一是网络状态非常好可以和世界上任何一个服务器连接无等待，一般欧盟、日本、美国，这些地方类型一。

其次是类型二是连接可能需要等待一段时间进入游戏后也比较稳定不会轻易掉线大部分地区都是类型二，在国内一般是港澳台三地和内陆联通网络用户是类型二。

至于类型三是连接可能会出错掉线，不建议用类型3去玩联网游戏或者网络游戏。然后就是NA无网络模式完全不能上网。

扩展资料：

NAT类型有三种情况：

1、NAT1是指直连。2、NAT2是通过路由器连接。3、网络类型为NAT3的意思是一些功能受限，电脑不能参加联机，参加派对不能说话，相当于自己给自己关小黑屋。

NAT类型检测：

前提条件:有一个公网的Server并且绑定了两个公网IP(IP-1,IP-2)。这个Server做UDP监听(IP-1,Port-1),(IP-2,Port-2)并根据客户端的要求进行应答。

第一步：检测客户端是否有能力进行UDP通信以及客户端是否位于NAT后。

1、客户端建立UDP socket然后用这个socket向服务器的(IP-1,Port-1)发送数据包要求服务器返回客户端的IP和Port, 客户端发送请求后立即开始接收数据包，要设定socket Timeout（300ms），防止无限堵塞。

重复这个过程若干次。如果每次都超时，无法接收到服务器的回应，则说明客户端无法进行UDP通信，可能是防火墙或NAT阻止UDP通信，这样的客户端也就 不能P2P了（检测停止）。

2、当客户端能够接收到服务器的回应时，需要把服务器返回的客户端（IP,Port）和这个客户端socket的 （LocalIP，LocalPort）比较。如果完全相同则客户端不在NAT后，这样的客户端具有公网IP可以直接监听UDP端口接收数据进行通信（检 测停止）。否则客户端在NAT后要做进一步的NAT类型检测(继续)。

第二步：检测客户端NAT是否是Full Cone NAT。

客户端建立UDP socket然后用这个socket向服务器的(IP-1,Port-1)发送数据包要求服务器用另一对(IP-2,Port-2)响应客户端的请求往回 发一个数据包,客户端发送请求后立即开始接收数据包，要设定socket Timeout（300ms），防止无限堵塞. 重复这个过程若干次。

如果每次都超时，无法接收到服务器的回应，则说明客户端的NAT不是一个Full Cone NAT，具体类型有待下一步检测(继续)。如果能够接收到服务器从(IP-2,Port-2)返回的应答UDP包，则说明客户端是一个Full Cone NAT，这样的客户端能够进行UDP-P2P通信（检测停止）。

第三步：检测客户端NAT是否是Symmetric NAT。

1、客户端建立UDP socket然后用这个socket向服务器的(IP-1,Port-1)发送数据包要求服务器返回客户端的IP和Port。

客户端发送请求后立即开始接收数据包，要设定socket Timeout（300ms），防止无限堵塞。重复这个过程直到收到回应（一定能够收到，因为第一步保证了这个客户端可以进行UDP通信）。

2、用同样的方法用一个socket向服务器的(IP-2,Port-2)发送数据包要求服务器返回客户端的IP和Port。

---