# Query not working unless adding preference=\_local? **URL:** \ **Category:** Elasticsearch\ **Created:** [May 11, 2014, 4:38am UTC](https://discuss.elastic.co/t/query-not-working-unless-adding-preference--local/17445 "2014-05-11T04:38:37Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![arthurx](https://avatars.discourse-cdn.com/v4/letter/a/ecd19e/32.png) [@arthurx](https://discuss.elastic.co/u/arthurx)\ **Post date:** [May 11, 2014, 4:38am UTC](https://discuss.elastic.co/t/query-not-working-unless-adding-preference--local/17445/1 "2014-05-11T04:38:37Z")
I had this strange issue that when I connect a second node to my originall node, most query posted to theh original node would have no response. But when those query are added preference=\_local , they willl work again. When I check cluster status and even logs on both nodes, everything looks fine. I suspect that it is the firewall of the new node that is rejecting query route from the original node, but then I check both 9200 and 9300 is opened. Would it be the case that another port is used in this scenario? And if not, where might I further debug this issue? -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/189c01cb-589c-4e70-9ade-93813a67b1d1%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/189c01cb-589c-4e70-9ade-93813a67b1d1%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 1:30am UTC](https://discuss.elastic.co/t/query-not-working-unless-adding-preference--local/17445/2 "2017-07-06T01:30:19Z")