Whenever I am executing curl command to query my Elasticsearch Instance, I am seeing it is trying to connect to random IP 208.73.211.70
curl -4 -u admin:root123 localhost:9200/amas/tasks/_search?pretty -v
* About to connect() to localhost port 9200 (#0)
* Trying 208.73.211.70...
I have not configured this IP anywhere in my configuration. Does anyone have idea what might be happening ?
That's something cURL is doing. If there is no Elasticsearch instance running on 208.73.211.70 it's not even reaching Elasticsearch.
Maybe you have a weird settings in hosts or some broken DNS entries?
Entry for localhost was missing in my /etc/hosts file. Because of which localhost was getting resolved to my domain address instead of 127.0.0.1. Adding localhost entry in /etc/hosts file resolved it.
Related
I'm trying to run the official Caddy 2 docker image. According to that page, to do that you should run:
docker run -p 80:80 \
-v $PWD/index.html:/usr/share/caddy/index.html \
-v caddy_data:/data \
caddy
When I run this, I get the following error:
{"level":"info","ts":1590185286.853735,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"}
run: loading initial config: loading new config: starting caddy administration endpoint: listen tcp 45.90.28.0:2019: bind: cannot assign requested address
I'm not sure why it's trying to bind to that IP address by default? I tried changing it in the Caddyfile but it still doesn't bind correctly, and anyway that doesn't really solve the underlying issue here.
What could be causing this problem? Should I be using Caddy 1 instead?
I experienced this issue recently on Linux and the root cause for me was that my ISP supplied routers DNS server was resolving localhost to an incorrect IP address.
You might want to try changing your DNS servers to Cloudflare's 1.1.1.1 or Google's 8.8.8.8 servers.
I started an instance on AWS ec2 and am trying to connect via my web browser to the app on the server running on port 3000. I've also turned off iptables...
I can telnet via telnet localhost 3000 and telnet 127.0.0.1 3000 but can't telnet via the hostname or ip like telnet ipaddress 3000.
When i do that, I get a connection refused. I think this has somethign to do with my hosts file but can't figure out what. My host file looks like this:
127.0.0.1 ip-108-205-72-168
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost6 localhost6.localdomain6
Provided that you gave the instance a public ip, have you checked the security groups? AWS security groups are associated with instances and apply inbound/outbound rules.
If you have already done that then my next step would probably be to make sure that the port is bound to the correct interface(s). ss -tupan | grep 3000
please make sure you iptable rules is right and can accessed by ip.
Could you confirm whether you using elastic IP over the amazon VM?
If yes, then it will do the entry in the host file automatically when you associate elastic IP to the EC2.
But if not, then need to do a manual entry.
Thanks,
SIM
I was using nodejs + nano + couchdb for my application successfully up until today. For some reason all of a sudden I'm getting ECONNREFUSED when I try to run my application. If I try to query the database using the web browser or using a different application (java application) it works fine. I'm uncertain why just in this scenario it stopped working. I've been researching for the past 2 days and can't find any help. I believe this might have something to do with too many open connections, but that's a little bit out of my realm of knowledge. Can anyone provide me with any insight on debugging this issue or any direction I could go in? I should mention this couchdb lives on iriscouch
Add more information about stack that you're using. But basically it's server machine doesn't want to allow connecting. Also try run your app with DEBUG=*, nano will log via console.log almost everything.
E.g. change in package.json start command to node changetoyourapp.js DEBUG=*
I faced yesterday same issue with nodejitsu/iriscouch. Issue disappeared after some restarts.
Check the version of your node vs the expected node version of nano. It is possible that nano does not work with node > 16.
This is down to Node v18 now preferring an IPv6 address over and IPv4 address if two exist for the same hostname.
i.e. if your /etc/hosts contains entries like this:
127.0.0.1 localhost
::1 localhost
Node v16 will say that "localhost" resolves to 127.0.0.1 where Node v18 will say "localhost" resolves to ::1, the IPv6 equivalent. As CouchDB doesn't listen on an IPv6 port by default, then a connection to ::1 will be refused.
Solutions:
Use 127.0.0.1 instead of localhost in your URLs.
Use a domain name that resolves unambiguously to an IPv4 address e.g. 127.0.0.1 my.pretend.host in your /etc/hosts file.
Revert to Nodev16 which preferred IPv4 addresses in its dns lookup.
Make CouchDB bind to an IPv6 address by changing bind_address = ::1 in couchdb.ini. You can then do curl 'http://USER:PASS#[::1]:5984/.
See
https://github.com/apache/couchdb-nano/issues/313#issuecomment-1321760360
I downloaded Apache2 and it is currently running. I typed in my IP address and it brings me to the "It Works!" page, however when I type in localhost or 127.0.0.1 I receive an error. Can someone tell me whats up?
check 127.0.0.1 able to ping or not with same machine.
check /etc/hosts file having 127.0.0.1 entry or not?
check in apache configuration file Listen 0.0.0.0:80 or not?
I have a centOS system(embedded and has very binaries) with the following /etc/hosts.
$cat /etc/hosts
127.0.0.1 localhost localhost
Also the host is assigned a DNS server which returns some invalid IP for the domain name lookup of localhost. But I cannot avoid a connection to this DNS due to some network restrictions.
My question is, when I already have a valid /etc/hosts file why is the system querying the DNS for localhost? And how can I stop that?
Any help would be greatly appreciated.
Check that you have files listed before dns for the hosts entry in /etc/nsswitch.conf.
[me#home]$ grep "^hosts" /etc/nsswitch.conf
hosts: files dns
If dns comes first, then your system will always query DNS to resolve hostnames before falling back to /etc/hosts.