Windows10下Docker运行ElasticSearch无法通过curl访问默认地址

在Windows 10系统中运行ElasticSearch Docker镜像时，无法通过0.0.0.0:9200使用curl访问，但127.0.0.2:9200可以正常响应。

执行的命令 #

$ docker pull docker.elastic.co/elasticsearch/elasticsearch:6.3.2

$ docker run -d --name es -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" docker.elastic.co/elasticsearch/elasticsearch:6.3.2
e8be84174fec0bcb796265d93e67ec70b6ac77a54a4ff65be7a51f9a64037f43

容器列表 #

docker container ls
CONTAINER ID   IMAGE                                                 COMMAND                  CREATED        STATUS        PORTS                                            NAMES
572b79717617   docker.elastic.co/elasticsearch/elasticsearch:6.3.2   "/usr/local/bin/dock…"   12 hours ago   Up 12 hours   0.0.0.0:9200->9200/tcp, 0.0.0.0:9300->9300/tcp   es
9ff0b5b40306   acerab/foodtrucks-web                                 "bash"                   14 hours ago   Up 14 hours   5000/tcp

ElasticSearch容器日志 #

$ docker container logs es

OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
[2023-01-19T03:57:00,940][INFO ][o.e.n.Node               ] [] initializing ...
[2023-01-19T03:57:01,007][INFO ][o.e.e.NodeEnvironment    ] [-dsoNEx] using [1] data paths, mounts [[/ (overlay)]], net usable_space [233.8gb], net total_space [250.9gb], types [overlay]
[2023-01-19T03:57:01,007][INFO ][o.e.e.NodeEnvironment    ] [-dsoNEx] heap size [989.8mb], compressed ordinary object pointers [true]
[2023-01-19T03:57:01,010][INFO ][o.e.n.Node               ] [-dsoNEx] node name derived from node ID [-dsoNExNSMmYeeQDYc3-Og]; set [node.name] to override
[2023-01-19T03:57:01,010][INFO ][o.e.n.Node               ] [-dsoNEx] version[6.3.2], pid[1], build[default/tar/053779d/2018-07-20T05:20:23.451332Z], OS[Linux/5.10.102.1-microsoft-standard-WSL2/amd64], JVM["Oracle Corporation"/OpenJDK 64-Bit Server VM/10.0.2/10.0.2+13]
[2023-01-19T03:57:01,010][INFO ][o.e.n.Node               ] [-dsoNEx] JVM arguments [-Xms1g, -Xmx1g, -XX:+UseConcMarkSweepGC, -XX:CMSInitiatingOccupancyFraction=75, -XX:+UseCMSInitiatingOccupancyOnly, -XX:+AlwaysPreTouch, -Xss1m, -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true, -XX:-OmitStackTraceInFastThrow, -Dio.netty.noUnsafe=true, -Dio.netty.noKeySetOptimization=true, -Dio.netty.recycler.maxCapacityPerThread=0, -Dlog4j.shutdownHookEnabled=false, -Dlog4j2.disable.jmx=true, -Djava.io.tmpdir=/tmp/elasticsearch.mV5lGAl6, -XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=data, -XX:ErrorFile=logs/hs_err_pid%p.log, -Xlog:gc*,gc+age=trace,safepoint:file=logs/gc.log:utctime,pid,tags:filecount=32,filesize=64m, -Djava.locale.providers=COMPAT, -XX:UseAVX=2, -Des.cgroups.hierarchy.override=/, -Des.path.home=/usr/share/elasticsearch, -Des.path.conf=/usr/share/elasticsearch/config, -Des.distribution.flavor=default, -Des.distribution.type=tar]
[2023-01-19T03:57:03,139][INFO ][o.e.p.PluginsService     ] [-dsoNEx] loaded plugin [ingest-user-agent]
[2023-01-19T03:57:06,403][INFO ][o.e.x.s.a.s.FileRolesStore] [-dsoNEx] parsed [0] roles from file [/usr/share/elasticsearch/config/roles.yml]
[2023-01-19T03:57:06,987][INFO ][o.e.x.m.j.p.l.CppLogMessageHandler] [controller/118] [Main.cc@109] controller (64 bit): Version 6.3.2 (Build 903094f295d249) Copyright (c) 2018 Elasticsearch BV
[2023-01-19T03:57:07,660][INFO ][o.e.d.DiscoveryModule    ] [-dsoNEx] using discovery type [single-node]
[2023-01-19T03:57:08,732][INFO ][o.e.n.Node               ] [-dsoNEx] initialized
[2023-01-19T03:57:08,732][INFO ][o.e.n.Node               ] [-dsoNEx] starting ...
[2023-01-19T03:57:08,944][INFO ][o.e.t.TransportService   ] [-dsoNEx] publish_address {172.17.0.2:9300}, bound_addresses {0.0.0.0:9300}
[2023-01-19T03:57:08,962][WARN ][o.e.b.BootstrapChecks    ] [-dsoNEx] max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
[2023-01-19T03:57:08,998][INFO ][o.e.x.s.t.n.SecurityNetty4HttpServerTransport] [-dsoNEx] publish_address {172.17.0.2:9200}, bound_addresses {0.0.0.0:9200}
[2023-01-19T03:57:08,999][INFO ][o.e.n.Node               ] [-dsoNEx] started

访问测试结果 #

• 执行curl 0.0.0.0:9200无响应
• 执行curl 127.0.0.2:9200得到正常响应：

StatusCode        : 200
StatusDescription : OK
Content           : {
                      "name" : "-dsoNEx",
                      "cluster_name" : "docker-cluster",
                      "cluster_uuid" : "UzUGppOxQ5ePcxLNB49HvA",
                      "version" : {
                        "number" : "6.3.2",
                        "build_flavor" : "default",
                        "build_type" : "ta...
RawContent        : HTTP/1.1 200 OK
                    Content-Length: 494
                    Content-Type: application/json; charset=UTF-8

                    {
                      "name" : "-dsoNEx",
                      "cluster_name" : "docker-cluster",
                      "cluster_uuid" : "UzUGppOxQ5ePcxLNB49HvA",
                      "vers...
Forms             : {}
Headers           : {[Content-Length, 494], [Content-Type, application/json; charset=UTF-8]}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        : mshtml.HTMLDocumentClass
RawContentLength  : 494

问题根源 #

1. PowerShell的curl并非原生工具：Windows PowerShell里的curl是Invoke-WebRequest的别名，它对0.0.0.0的解析逻辑和Linux/macOS原生curl不同，无法正确映射到本地回环地址。
2. WSL2网络映射特性：Docker在WSL2模式下，容器端口绑定到0.0.0.0，但Windows主机访问时，0.0.0.0不会被正确解析到WSL2的虚拟网络接口，而回环地址（如127.0.0.1、127.0.0.2）可以正常穿透。

解决办法 #

方法1：直接使用回环地址访问 #

用curl 127.0.0.1:9200替代0.0.0.0:9200，回环地址能稳定映射到容器绑定的端口。

方法2：安装原生curl工具 #

下载Windows版原生curl并添加到系统PATH，之后执行curl 0.0.0.0:9200即可正常访问，原生curl对0.0.0.0的解析符合通用标准。

方法3：在WSL2终端内执行curl #

打开WSL2的Linux终端（如Ubuntu），直接在里面执行curl 0.0.0.0:9200——WSL2和Docker容器处于同一网络环境，能直接访问绑定到0.0.0.0的端口。

补充：修复ElasticSearch内存警告 #

日志中提示max virtual memory areas vm.max_map_count [65530] is too low，虽不影响当前访问，但可能导致性能问题或后续运行异常。可在WSL2中执行以下操作：

• 临时生效：

sudo sysctl -w vm.max_map_count=262144

• 永久生效：编辑/etc/sysctl.conf，添加一行vm.max_map_count=262144，保存后执行sudo sysctl -p生效。

内容的提问来源于stack exchange，提问作者Abhi