No route to host 之http_proxy

这不是一篇技术文章。主要说的是工作中沟通与交流的事情。其中涉及到linux中设置代理的两种方式。

http_proxy 于 https_proxy 分别对应不同的访问协议，这个小常识应该引起注意。

 

背景：

北京的 A同学要使用位于成都的某台Linux Server与外部公司做接口调试。

 

第一天：

A同学做了如下的测试： 

# wget https://112.168.0.13:443                

--2014-08-01 17:12:39--  https://112.168.0.13/

Connecting to 112.168.0.13:443... failed: No route to host.

A同学向位于成都的B同学发邮件反映情况，说访问不通那个IP地址。

B同学收到邮件后，说这台机器访问外网要设置代理。

 

第二天：

 A 同学以为B同学会在服务器上设置默认的代理，于是进行同样的测试。但还是访问不通。依旧邮件反馈给B同学。

 B同学收到邮件后要求A同学截图。

 A同学将操作的截图发给B同学。

 

第三天：

B 同学看到A同学的邮件后，发现A同学并没有设置代理。

于是他将设置代理的命令发给A同学。

export http_proxy=http://10.30.19.19:8080

 A 同学收到邮件后，按B同学给的命令设置了代理，进行测试，发现依旧不通。于是将截图又发给B同学。

B同学看到邮件后，发现这是个新地址，代理并没有允许访问这个地址。于是将这个新的IP地址加到代理允许访问的规则里。并让A同学重试。

A同学重试，依旧不通。并将截图发给B同学。

 

第四天：

B 同学看到邮件后，开始进行测试。

export http_proxy=http://10.30.19.19:8080

1.  Ping  ip   不通

2.  telnet  ip  port  也是不通。

3.  wget https://112.168.0.13:443   显示No route to host.

B同学将测试结果发给A同学，并问是不是对方的防火墙有限制。

A 同学问过外部公司的负责人，对方表示防火墙没有限制。

 

第五天：

项目经理问这个项目的进展情况，A同学如实汇报。

由于网管离职，项目经理找D同学一起讨论这个问题。D也是个半吊子，不怎么懂网络。

D问是不是需要加一条路由过去，A说北京的一台机器没加也能访问通。

于是D同学让A 同学去演示一下。

A同学在北京的机器上访问了一下，

wget https://112.168.0.13:443也是同样的错误No route to host

D同学说没设置代理吧。

A 同学设置代理后也是报同样的错误。

项目经理问：这个是怎么回事？

A 同学说程序里是正常的啊，天天都在测试，没问题啊。

于是让A同学看程序里设置的代理。

原来是

export https_proxy=http://10.29.19.18:8888

而刚才在server上设置的代理是export http_proxy=http://10.29.19.18:8888

在server上于程序中的区别是：一个是http_proxy , 一个是https_proxy 

于是在北京server上用https_proxy , 再去wget果然通了。

 在成都的机器上用https_proxy 也通了。

 

 一个简单的问题，用了5天才解决。是问题很难吗？

 

总结：

1. 在遇到自己解决不了的问题时，换个思路多尝试一下，或者找人讨论一下，未尝不是个好方法。

    自己不能解决问题，还不主动沟通交流，在工作中的确是个大问题。

2.  其实谁都不是全才，工作中都会遇到自己解决不了的问题。三人行必有我师。有时候要放低姿态，想周围人请教一下。

     也不是什么丢脸的事请。也许别人能帮了你，体现出了他的价值，他还很高兴呢。

3.  有时候邮件沟通，效率的确不高。也许就是一两句话的事情，邮件却要反复多少遍才能解决。当然邮件在工作中还是很重要的。

     但我们不能依赖邮件去做任何事情。