# Filebeat setup: 400 Bad Request no handler found for uri \[//\_ilm/policy/filebeat\]

**URL:** https://discuss.elastic.co/t/filebeat-setup-400-bad-request-no-handler-found-for-uri-ilm-policy-filebeat/311900
**Category:** Beats
**Tags:** ilm-index-lifecycle-management, filebeat
**Created:** [August 11, 2022, 6:33am UTC](https://discuss.elastic.co/t/filebeat-setup-400-bad-request-no-handler-found-for-uri-ilm-policy-filebeat/311900 "2022-08-11T06:33:40Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![Nick95](https://avatars.discourse-cdn.com/v4/letter/n/8e7dd6/32.png) [@Nick95](https://discuss.elastic.co/u/Nick95)
#### Post date: [August 11, 2022, 6:33am UTC](https://discuss.elastic.co/t/filebeat-setup-400-bad-request-no-handler-found-for-uri-ilm-policy-filebeat/311900/1 "2022-08-11T06:33:40Z")

</div>

Hi,

I try to run a filebeat on a server. Elastic and Kibana are installed on another server and are pushed on 443 port via a nginx reverse proxy. Kibana GUI is working on the IP I set up (https with self-generated certificate)

When I run # sudo filebeat setup, I get a 400 bad request error:

\*Exiting: failed to check for policy name 'filebeat': (status=400) {"error":"no handler found for uri [//\_ilm/policy/filebeat] and method [GET]"}: 400 Bad Request: {"error":"no handler found for uri [//\_ilm/policy/filebeat] and method [GET]\*

I try to troubleshoot but I can’t see where is the issue.

**Filebeat.yml On the filebeat server (only the uncommented lines)**

```auto
# ============================== Filebeat inputs ===============================

filebeat.inputs:

- type: filestream

  id: my-filestream-id

  enabled: false

  paths:

    - /var/log/*.log

# ============================== Filebeat modules ==============================

filebeat.config.modules:

  path: ${path.config}/modules.d/*.yml

  reload.enabled: false

# ================================== Outputs ===================================

# ---------------------------- Elasticsearch Output ----------------------------

output.elasticsearch:

  hosts: ["<IP-ES-KIBANA>:443 /es"]

  ssl.certificate: "/ca/ca.crt"

  ssl.key: "/ca/ca.key"

  ssl.verification_mode: "none"

# ================================= Processors =================================

processors:

  - add_host_metadata:

      when.not.contains.tags: forwarded

  - add_cloud_metadata: ~

  - add_docker_metadata: ~

  - add_kubernetes_metadata: ~

```

**Nginx conf on the Elastic/Kibana server**

```auto
server {

  listen 443 ssl; 

  server_name <IP-ES-KIBANA>;

 

  ssl on;

  ssl_certificate /ca/ca.crt;

  ssl_certificate_key /ca/ca.key;

 

  location /kibana {

    proxy_pass http://localhost:5601;

      }

 

  location /es {

    proxy_pass http://localhost:9200/;

    #proxy_read_timeout 90;

  }

}

```

Version filebeat: 8.2.2 / Version Elastic search: 8.2.2

Can someone help please?

Thanks in advance,

Nick

---

<div class="post-metadata">

### Author: ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)
#### Post date: [August 11, 2022, 6:34am UTC](https://discuss.elastic.co/t/filebeat-setup-400-bad-request-no-handler-found-for-uri-ilm-policy-filebeat/311900/2 "2022-08-11T06:34:22Z")

</div>

Does it work if you talk directly to Elasticsearch/without nginx?

---

<div class="post-metadata">

### Author: ![Nick95](https://avatars.discourse-cdn.com/v4/letter/n/8e7dd6/32.png) [@Nick95](https://discuss.elastic.co/u/Nick95)
#### Post date: [August 11, 2022, 6:38am UTC](https://discuss.elastic.co/t/filebeat-setup-400-bad-request-no-handler-found-for-uri-ilm-policy-filebeat/311900/3 "2022-08-11T06:38:47Z")

</div>

Hi, yes if filebeat is installed locally behind the reverse proxy, it is working well and I can see logs on Kibana. It is when I try to set up filebeat on another server that I got the issue.

---

<div class="post-metadata">

### Author: ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)
#### Post date: [August 12, 2022, 12:36am UTC](https://discuss.elastic.co/t/filebeat-setup-400-bad-request-no-handler-found-for-uri-ilm-policy-filebeat/311900/4 "2022-08-12T00:36:53Z")

</div>

Then it is likely an nginx redirect issue.

---

<div class="post-metadata">

### Author: ![Nick95](https://avatars.discourse-cdn.com/v4/letter/n/8e7dd6/32.png) [@Nick95](https://discuss.elastic.co/u/Nick95)
#### Post date: [August 18, 2022, 12:40pm UTC](https://discuss.elastic.co/t/filebeat-setup-400-bad-request-no-handler-found-for-uri-ilm-policy-filebeat/311900/5 "2022-08-18T12:40:45Z")

</div>

Hi,

To troubleshoot/simplify, I put everything on http and I still have the same issue.

I check in the log on my working filebeat locally and the correct message should be:

_{"log.level":"info","@timestamp":"2022-08-10T09:31:43.699+0200","log.logger":"index-management.ilm","log.origin":{"[file.name](http://file.name/)":"ilm/std.go","file.line":118},"message":"ILM policy filebeat exists already.","[service.name](http://service.name/)":"filebeat","ecs.version":"1.6.0"}_

So clearly filebeat on the remote server is failing to reach the correct kibana url. On remote server:

_# curl -I http://\<IP-ES-KIBANA/es give 200 OK_

_# curl -I http://\<IP-ES-KIBANA/kibana give 302 FOUND_

_# curl -I http://\<IP-ES-KIBANA/kibana/app/home give 200 OK_

Using NGINX reverse proxy is pretty standard so I don’t understand where the issue come from.

Maybe something is missing in the configuration of filebeat.yml or nginx.conf ...

---

<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: [September 15, 2022, 2:41pm UTC](https://discuss.elastic.co/t/filebeat-setup-400-bad-request-no-handler-found-for-uri-ilm-policy-filebeat/311900/6 "2022-09-15T14:41:12Z")

</div>

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