# Proxyconnect tcp: tls: first record does not look like a TLS handshake metricbeat monitoring elasticsearch

**URL:** https://discuss.elastic.co/t/proxyconnect-tcp-tls-first-record-does-not-look-like-a-tls-handshake-metricbeat-monitoring-elasticsearch/253567
**Category:** Beats
**Tags:** metricbeat
**Created:** [October 28, 2020, 1:33pm UTC](https://discuss.elastic.co/t/proxyconnect-tcp-tls-first-record-does-not-look-like-a-tls-handshake-metricbeat-monitoring-elasticsearch/253567 "2020-10-28T13:33:56Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![Adriann](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/adriann/32/77780_2.png) [@Adriann](https://discuss.elastic.co/u/Adriann)
#### Post date: [October 28, 2020, 1:33pm UTC](https://discuss.elastic.co/t/proxyconnect-tcp-tls-first-record-does-not-look-like-a-tls-handshake-metricbeat-monitoring-elasticsearch/253567/1 "2020-10-28T13:33:56Z")

</div>

Hello,

I wanted to set up beats monitoring for my enviroment. But it does not work and I see this error in the logs.

```
2020-10-28T14:25:23.636+0100	INFO	[monitoring]	elasticsearch/elasticsearch.go:245	Failed to connect to Elastic X-Pack Monitoring. Either Elasticsearch X-Pack monitoring is not enabled or Elasticsearch is not available. Will keep retrying. Error: cannot connect underlying Elasticsearch client: Get "https://dns.pl:9200": proxyconnect tcp: tls: first record does not look like a TLS handshake

```

This is how my metricbeat configuration looks like.

```
monitoring:
    enabled: true
    cluster_uuid: "someuuidtakenfromserver"
    elasticsearch:
        hosts: ["https://dns.pl:9200"]
        username: "${ES_LOG}"
        password: "${ES_PWD}"
        ssl.certificate_authorities: ["pathcerts/ca.crt"]
        ssl.certificate: "path/certs/beats.crt"
        ssl.key: "path/certs/beats.key"
        ssl.verification_mode: "none"
        proxy_disable: true	

```

This is how my monitoring cluster node looks like.

```
xpack.security.enabled: true
xpack.security.http.ssl.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.http.ssl.key: certs/node1/node1.key
xpack.security.http.ssl.certificate: certs/node1/node1.crt
xpack.security.http.ssl.certificate_authorities: certs/ca/ca.crt
xpack.security.transport.ssl.key: certs/node1/node1.key
xpack.security.transport.ssl.certificate: certs/node1/node1.crt
xpack.security.transport.ssl.certificate_authorities: certs/ca/ca.crt
xpack.security.transport.ssl.verification_mode: certificate
xpack.monitoring.enabled: true
xpack.monitoring.collection.enabled: true
xpack.security.audit.enabled: true
discovery.type: single-node
script.max_compilations_rate: 3000/5m
search.max_buckets: 80000
cluster.max_shards_per_node: 3000

```

Everything else is working.  
Elasticsearch-pack from metricbeat that is on node server is working. Kibana monitoring is also working.

Roles are as below.

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/7/4/74f8e3848478c8c1e0dce4edd2f901d6be508012.png)  
 ![image](https://us1.discourse-cdn.com/elastic/original/3X/0/b/0b7be58d8bfad2978bc59aceca86fb45c0f14c9d.png)

If I just do

```
monitoring.enabled: true
monitoring.cluster_uuid: someuid

```

on a beat that is on the same server as clutser node everything works.

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/6/c/6c06427f44d9c80c742b464b7f0db9a119495ad9.png)

What am I doing wrong?

EDITED:

I guess this issue is related to [this](https://github.com/elastic/elasticsearch/issues/31725)  
But what should I do If I configured xpack as in [this](https://www.elastic.co/blog/configuring-ssl-tls-and-https-to-secure-elasticsearch-kibana-beats-and-logstash#run-filebeat) thread?

---

<div class="post-metadata">

### Author: ![Adriann](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/adriann/32/77780_2.png) [@Adriann](https://discuss.elastic.co/u/Adriann)
#### Post date: [October 29, 2020, 1:29am UTC](https://discuss.elastic.co/t/proxyconnect-tcp-tls-first-record-does-not-look-like-a-tls-handshake-metricbeat-monitoring-elasticsearch/253567/2 "2020-10-29T01:29:51Z")

</div>

So after testing a lot of things for hours It just looks like the

` proxy_disable: true`

and

```
proxy_url : ""

```

does not behave like documented.

---

<div class="post-metadata">

### Author: ![Adriann](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/adriann/32/77780_2.png) [@Adriann](https://discuss.elastic.co/u/Adriann)
#### Post date: [October 29, 2020, 2:11am UTC](https://discuss.elastic.co/t/proxyconnect-tcp-tls-first-record-does-not-look-like-a-tls-handshake-metricbeat-monitoring-elasticsearch/253567/3 "2020-10-29T02:11:17Z")

</div>

After enabling beat-xpack and adding configuration to every beat  
http.enabled: true  
http.port: 506X  
monitoring.enabled: false

to beats I got the data I wanted.

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/e/d/ed2d04388da84babb173df2846c05a9993d39e13.png)

---

<div class="post-metadata">

### Author: ![Adriann](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/adriann/32/77780_2.png) [@Adriann](https://discuss.elastic.co/u/Adriann)
#### Post date: [October 29, 2020, 5:54pm UTC](https://discuss.elastic.co/t/proxyconnect-tcp-tls-first-record-does-not-look-like-a-tls-handshake-metricbeat-monitoring-elasticsearch/253567/5 "2020-10-29T17:54:34Z")

</div>

This is still no perfect because it somehow rotates the beats info...

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/c/6/c63a12ef4ef69f3aab590e8d3851bc48d2e3d53b.png)  
I have the same configuration on 6 servers. But the system sees only one kind of a beat and constantly changes the name.

---

<div class="post-metadata">

### Author: ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)
#### Post date: [November 26, 2020, 7:54pm UTC](https://discuss.elastic.co/t/proxyconnect-tcp-tls-first-record-does-not-look-like-a-tls-handshake-metricbeat-monitoring-elasticsearch/253567/6 "2020-11-26T19:54:43Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
