ダウンロードして展開してハイlocalhost:9200でアクセスできました。じゃあウチの環境に合わせてアクセスしやすいようにちょっと設定変えるか、アレ動かないぞ、どうすりゃいいんだ。というよくあるやつ。
セキュリティの問題もあるので正しく設定したい。0.0.0.0に逃げるのは無し。

バージョンとか

Windows版
Elasticsearch 6.7.2～を想定
もっと古いと書き方が違う。

elasticsearch.yml

\config\elasticsearch.yml
ほとんどの設定はこれに書く。何か違っているとブートストラップチェックで容赦なく止まる。
Windows版だとShift-JISであり、このままだとコメントに日本語を書くとエラーになる。半角カタカナもだめ。日本語コメントを付けたい場合UTF8にすること。

network.host設定

この設定の意味

公式のリファレンス

Elasticsearchはデフォルトではlocalhostからのリクエストしか受け付けない。他からのリクエストを受け付けさせる時にこの設定を編集する。
「network.hostに書いたIPアドレスからのリクエストを受け付ける」ではない。
「network.hostに書いた名前でリクエストされたら返事する」が正解。

network.host
ノードはこのホスト名またはIPアドレスにバインドし、このホストをクラスター内の他のノードに公開（アドバタイズ）します。

初めてElasticsearch使いだした頃、ここの勘違いで3日くらい流れた思い出深い設定箇所。世界中の質問サイトに似たような勘違いをした質問があって惑わされまくった…。

特別な値

IPアドレスの他、いくつかの特別な語で指定が可能。
公式リファレンスに特別な値について記載がある。

_[networkInterface]_
たとえば、ネットワークインターフェイスのアドレス_en0_。
_local_
システム上のループバックアドレス（例：）127.0.0.1。
_site_
システム上のサイトローカルアドレス（例：）192.168.0.1。
_global_
システム上のグローバルスコープのアドレス（例：）8.8.8.8。

_[networkInterface]_

特定のNICから来るリクエストを受け付ける。存在しないインターフェースを指定するとブートストラップチェックで止まる。
書き方のバリエーションがいろいろあって、複数NICがあってクラスタ組むときに使うと便利に指定できるらしい。

_local_

localhostでのリクエストを受け付ける。デフォルト値。
他の指定するときにうっかり書き忘れて、localhost:9200でアクセスできない！とあせるのはよくあること。

_site_

いわゆるプライベートIPアドレスでのリクエストを受け付ける。セグメント異なっていてもOK。 ~~クラスの異なるプライベートIPアドレス間で受けられるかは試してない。~~ クラスが異なってもプライベートIPアドレスであれば受け付ける。

補足：サイトローカルアドレス
古いIPv6用語で、IPv6でIPv4同様のプライベートアドレスのことを指して一時期使われていた言葉。昔IPv6について勉強した人は聞いたことのある言葉のはず。
ElasticsearchはIPv6を受け付けているのでこの言葉を使って表現し、今もリファレンスを直してないままのようだ。
現在は廃止になって「ユニークローカルアドレス」という別の規格が定められている。
RFC 4193

_global_

グローバルIPアドレスでのリクエストを受け付ける。外部公開してしまう要注意設定。
グローバルアドレスの存在を検知できない場合、ブートストラップチェックで止まる。

とりあえず動かしてみたいなら

network.host: _local_,_site_
discovery.type: single-node

single-nodeについてはこちらの記事を参照のこと。
シングル構成のelasticsearchでnetwork.hostを設定すると起動しない（development modeとproduction mode ）

セキュリティ問題

良くない設定：0.0.0.0

0.0.0.0を設定するとどこからのアクセスでも受け付けるようになる。セキュリティ上良くない。この設定はテストや問題の切り分けを行う特別な用途以外では使うべきでない。
こういうガバ設定に慣れてしまうのは「こんなものだろ」と油断精神に染まりそうなのも良くないと思う。

アクセス制御

_local_や_site_設定なら外からアクセスできない。しかし、ネットワーク内に侵入された場合はアクセスし放題、やはり良くない。あるいは、組織内部にいる不心得者がしてほしくない形で勝手なアクセスをするかもしれない、これも良くない。
業務利用では多少なりとセンシティブな情報扱うのだから、別の方法でアクセス制御をすべき。
公式ではX-Pack Securityで認証ユーザー設定する方法を紹介している。(6.8.0 / 7.1.0から無償化され誰でも使える)
Securityを始めてみよう

ファイアウォール等でセグメント別の制限を加えるとなお良い。防御は複数要素で。