Loopback Connections not Enabeled
We have recently spun up an unmanaged VPS over at 20i. We have used dedicated servers before from another provider UKFAST.
On transferring our wordpress sites we are finding that background processing seems to having some problems, and its become apparent that this is due to loopback connections not being enabled at server level?
I have scoured the internet and have so far been unable to find out how to enable this, all documentation points the host resolving it, though in this case 20i have told us its something we would have to fix.
We have full root access and SSH has been set up for the server. is this something that can be enabled through WHM/Cpanel?
-
Hey there - thanks for joining the forums! You are correct that this needs to be setup or resolved by the hosting provider, as this operates at a level deeper than the cPanel & WHM software. We do have some additional details on that here, including a test you can perform if the system is using a NAT networking configuration: 0 -
Hi Rex, Thanks for the fast reply! We've actually sent a link to this thread to the host and two testing sites and they have come back with this: >>> We've tested the loopbacks on the server and all seems to be fine: [root@vps-ab135a ~]# ifconfig lo lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1000 (Local Loopback) packets 616373 bytes 337503341 (321.8 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 616373 bytes 337503341 (321.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
is there anything else we can change or another setting we could be missing?0 -
I actually don't think that is related at all. There will always be a loopback interface that shows up in ifconfig. What happens if you run this command on the system? dig @1.2.3.4 . NS
In this example, 1.2.3.4 is your server's public IP address.0 -
I've just realised that the loopback connections are working on http connections - but not the https? ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7 <<>> 185.151.29.194 . NS ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53167 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;185.151.29.194. IN A ;; AUTHORITY SECTION: . 86393 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2020111300 1800 900 604800 86400 ;; Query time: 14 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Nov 13 15:16:17 GMT 2020 ;; MSG SIZE rcvd: 118 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23425 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 84110 IN NS a.root-servers.net. . 84110 IN NS b.root-servers.net. . 84110 IN NS c.root-servers.net. . 84110 IN NS d.root-servers.net. . 84110 IN NS e.root-servers.net. . 84110 IN NS f.root-servers.net. . 84110 IN NS g.root-servers.net. . 84110 IN NS h.root-servers.net. . 84110 IN NS i.root-servers.net. . 84110 IN NS j.root-servers.net. . 84110 IN NS k.root-servers.net. . 84110 IN NS l.root-servers.net. . 84110 IN NS m.root-servers.net. ;; Query time: 3 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Nov 13 15:16:17 GMT 2020 ;; MSG SIZE rcvd: 239 [root@vps-ab135a ~]# ^C [root@vps-ab135a ~]# 0 -
That's interesting as that does seem to work according to that output. It might be time to submit a ticket to our team so we can examine the system directly and see what's going on. If you do submit that ticket, please paste the number here so we can let everyone know what the ultimate resolution was. 0
Please sign in to leave a comment.
Comments
5 comments