我不太热衷于网络，但我遇到了以下问题。我正在研究Ubuntu 18.04.2 LTS我的客户网络内的服务器。
这里我遇到了以下问题，似乎与DNS解析有关。
如果我执行这个命令：
my.username@VHCLWSO2AS02:~$ nslookup google.com
;; connection timed out; no servers could be reached
看起来nslookup无法工作所以我获得超时。
奇怪的是，如果我表演获得命令进入我的shell它工作正常，事实上：
my.username@VHCLWSO2AS02:~$ wget google.com
--2020-02-17 15:19:53-- http://google.com/
Connecting to 127.0.0.1:3128... connected.
Proxy request sent, awaiting response... 301 Moved Permanently
Location: http://www.google.com/ [following]
--2020-02-17 15:19:53-- http://www.google.com/
Connecting to 127.0.0.1:3128... connected.
Proxy request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html’
index.html [ <=> ] 11.52K --.-KB/s in 0s
2020-02-17 15:19:53 (214 MB/s) - ‘index.html’ saved [11800]
正如你所见，它工作正常。我最初的疑问是：为什么nslookup不起作用，但是获得使用相同的google.com名字工作正常吗？
查看输出获得输出在我看来是通过代理。特别是我认为它应该是中央管理办公室安装在同一台机器上的代理（在3128同一台机器的端口：127.0.0.1）这是有道理的，因为客户网络应该使用需要身份验证才能访问 Internet 的 Windows 防火墙。
所以我的假设是，出于一些我不知道的原因，nslookup没有经过这个中央管理办公室代理，因此它不起作用。
我的推理正确吗？如果nslookup没有通过我的代理（就像 wget 那样）？我遗漏了什么？您是否有解决这种情况的想法？
答案1
您正在使用 HTTP 代理，即用于中继 HTTP 请求的代理，但nslookup 不是 HTTP 客户端首先，所以它甚至不会查看您的代理设置。
虽然从技术上来说 HTTP 代理能通常使用“CONNECT”方法传输 TCP 流——这是它们通常处理 HTTPS 站点的方式，而无需破坏 TLS 安全性。——大多数非 HTTP 工具本身不支持此功能，因为 1）大多数代理配置为仅有的允许流连接到 HTTPS 端口；2）此方法不能携带 UDP 数据报（nslookup 希望使用 UDP 和 TCP）。
如果只需要 TCP（并且如果代理允许连接到所需端口），您可能可以使用诸如 之类的包装器proxytunnel。
wget 之所以有效，是因为它实际上根本不需要为“google.com”执行 DNS 解析：它只需将原始 URL 提供http://google.com给代理，然后代理进行自己的 DNS 查找。