程序装进容器之后，网络这件事会和直接跑在机器上不太一样。容器的网络默认和宿主机隔了一层，宿主机上配好的代理IP，容器里的程序往往读不到。不少人因此卡住：明明在机器上试过没问题，装进容器就不管用了。差别出在容器自己的网络环境上。
容器网络和宿主机隔着一层
容器启动时会拿到自己的一套网络设置，包括独立的地址和路由。它在默认情况下不读宿主机的代理配置，也不共用宿主机的连接。所以宿主机上配好的那一层，对容器里的程序没有约束力。要让容器里的流量走代理，得把设置带进容器内部，或者在容器启动时把网络接法调整好。
- 容器内部配
- 在镜像或启动脚本里设好，容器自己读
- 启动时传入
- 用参数把设置带进容器，不改镜像
- 走宿主网络
- 容器直接用宿主机的网络设置，配置跟随宿主机
容器内部配
在容器内部设好环境变量，程序启动时就能读到。这种方式最直接，缺点是配置写在镜像里，换一条线路就得重新构建一次。把配置放在启动脚本里会灵活一些，同一个镜像可以带不同的参数跑起来。
启动时传入
启动容器时用参数把代理IP的设置传进去，镜像本身不动。这种方式适合同一个镜像要在不同线路上跑的场合，也不必为了换配置重新打包。参数写错时容器照样启动，只是网络没走对，所以启动之后要验证一次。
让容器跟随宿主机
把容器的网络模式设成和宿主机共用，容器就直接用宿主机的网络设置。宿主机上配了什么，容器就跟着用什么，改一处两边都变。代价是容器之间不再隔离，端口容易冲突，适合单个容器独占一台机器的场景。
选哪种
看容器数量和隔离要求。一台机器只跑一个容器，跟随宿主机最省事。一台机器跑多个容器、每个容器要用不同线路，就得在容器内部各配各的。
- 单容器独占机器，跟随宿主机最省事
- 多容器各走各的线路，容器内部各配一份
- 镜像要保持通用，用启动参数传入
- 不管哪种做法，启动后都要验证一次
容器读不到宿主机的配置，是这类问题最常见的原因。
容器里的网络要单独配一遍。
把设置放进容器内部、或者让容器共用宿主机的网络，两种做法各适合一类场景。容器数量一多，逐个在内部配置的维护量会明显上升，这时候就把配置集中在启动环节，用参数统一下发。容器环境下的代理IP接法，要处理的就是隔了一层带来的读取问题。先弄清容器读的是哪一层设置。