Port 80 connection refused
i can not connect to port 80 on my webserver.
my iptables are in the default state:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
when i start different servers (nginx, nodejs ...) i can make them listen to port 80, but trying to access, i always get "connection refused".
Listening to any other port (81,8080 whatever) works perfectly fine. Only port 80 is somehow blocked. Accessing port 80 via localhost does work, so for testing purpose i even switched of the external firewall, still no luck. What can i do to find out who is blocking this port 80?
as requested the output of netstat -tlpn (when running nginx on port 80):
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 710/vsftpd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1179/sshd
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 1661/master
tcp 0 0 0.0.0.0:5984 0.0.0.0:* LISTEN 980/beam.smp
tcp 0 0 87.106.64.11:3306 0.0.0.0:* LISTEN 1346/mysqld
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3274/nginx: master
tcp6 0 0 :::22 :::* LISTEN 1179/sshd
tcp6 0 0 :::25 :::* LISTEN 1661/master
networking server iptables nginx
|
show 2 more comments
i can not connect to port 80 on my webserver.
my iptables are in the default state:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
when i start different servers (nginx, nodejs ...) i can make them listen to port 80, but trying to access, i always get "connection refused".
Listening to any other port (81,8080 whatever) works perfectly fine. Only port 80 is somehow blocked. Accessing port 80 via localhost does work, so for testing purpose i even switched of the external firewall, still no luck. What can i do to find out who is blocking this port 80?
as requested the output of netstat -tlpn (when running nginx on port 80):
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 710/vsftpd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1179/sshd
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 1661/master
tcp 0 0 0.0.0.0:5984 0.0.0.0:* LISTEN 980/beam.smp
tcp 0 0 87.106.64.11:3306 0.0.0.0:* LISTEN 1346/mysqld
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3274/nginx: master
tcp6 0 0 :::22 :::* LISTEN 1179/sshd
tcp6 0 0 :::25 :::* LISTEN 1661/master
networking server iptables nginx
1
Please edit your question and add the output ofsudo netstat -tlpn
running from the server..
– heemayl
Sep 20 '15 at 21:48
Ubuntu and debian usually use ufw (uncomplicated firewall) and, oftentimes, the default is to block incoming and allow outgoing. Have you tried runningsudo ufw disable
on the server machine to see if that is the culprit? Additionally, you may need to set access by properly editing your/etc/apache2/sites-enabled
file.
– mchid
Sep 20 '15 at 21:55
Some ISPs and routers block port 80 access, keep that in mind. Is this on an offsite server or...?
– Thomas Ward♦
Sep 20 '15 at 21:58
thanks for your input, ufw staus is "inactive" and i don't have apache installed hence no /etc/apache2 folder... still the problem persists... and again on the server when i do lynx 127.0.0.1, all is well and works fine
– Holger Will
Sep 20 '15 at 22:03
nginx
is listening on port 80..check thenginx
logs..
– heemayl
Sep 20 '15 at 22:03
|
show 2 more comments
i can not connect to port 80 on my webserver.
my iptables are in the default state:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
when i start different servers (nginx, nodejs ...) i can make them listen to port 80, but trying to access, i always get "connection refused".
Listening to any other port (81,8080 whatever) works perfectly fine. Only port 80 is somehow blocked. Accessing port 80 via localhost does work, so for testing purpose i even switched of the external firewall, still no luck. What can i do to find out who is blocking this port 80?
as requested the output of netstat -tlpn (when running nginx on port 80):
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 710/vsftpd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1179/sshd
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 1661/master
tcp 0 0 0.0.0.0:5984 0.0.0.0:* LISTEN 980/beam.smp
tcp 0 0 87.106.64.11:3306 0.0.0.0:* LISTEN 1346/mysqld
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3274/nginx: master
tcp6 0 0 :::22 :::* LISTEN 1179/sshd
tcp6 0 0 :::25 :::* LISTEN 1661/master
networking server iptables nginx
i can not connect to port 80 on my webserver.
my iptables are in the default state:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
when i start different servers (nginx, nodejs ...) i can make them listen to port 80, but trying to access, i always get "connection refused".
Listening to any other port (81,8080 whatever) works perfectly fine. Only port 80 is somehow blocked. Accessing port 80 via localhost does work, so for testing purpose i even switched of the external firewall, still no luck. What can i do to find out who is blocking this port 80?
as requested the output of netstat -tlpn (when running nginx on port 80):
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 710/vsftpd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1179/sshd
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 1661/master
tcp 0 0 0.0.0.0:5984 0.0.0.0:* LISTEN 980/beam.smp
tcp 0 0 87.106.64.11:3306 0.0.0.0:* LISTEN 1346/mysqld
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3274/nginx: master
tcp6 0 0 :::22 :::* LISTEN 1179/sshd
tcp6 0 0 :::25 :::* LISTEN 1661/master
networking server iptables nginx
networking server iptables nginx
edited Sep 21 '15 at 7:51
Holger Will
asked Sep 20 '15 at 21:42
Holger WillHolger Will
181119
181119
1
Please edit your question and add the output ofsudo netstat -tlpn
running from the server..
– heemayl
Sep 20 '15 at 21:48
Ubuntu and debian usually use ufw (uncomplicated firewall) and, oftentimes, the default is to block incoming and allow outgoing. Have you tried runningsudo ufw disable
on the server machine to see if that is the culprit? Additionally, you may need to set access by properly editing your/etc/apache2/sites-enabled
file.
– mchid
Sep 20 '15 at 21:55
Some ISPs and routers block port 80 access, keep that in mind. Is this on an offsite server or...?
– Thomas Ward♦
Sep 20 '15 at 21:58
thanks for your input, ufw staus is "inactive" and i don't have apache installed hence no /etc/apache2 folder... still the problem persists... and again on the server when i do lynx 127.0.0.1, all is well and works fine
– Holger Will
Sep 20 '15 at 22:03
nginx
is listening on port 80..check thenginx
logs..
– heemayl
Sep 20 '15 at 22:03
|
show 2 more comments
1
Please edit your question and add the output ofsudo netstat -tlpn
running from the server..
– heemayl
Sep 20 '15 at 21:48
Ubuntu and debian usually use ufw (uncomplicated firewall) and, oftentimes, the default is to block incoming and allow outgoing. Have you tried runningsudo ufw disable
on the server machine to see if that is the culprit? Additionally, you may need to set access by properly editing your/etc/apache2/sites-enabled
file.
– mchid
Sep 20 '15 at 21:55
Some ISPs and routers block port 80 access, keep that in mind. Is this on an offsite server or...?
– Thomas Ward♦
Sep 20 '15 at 21:58
thanks for your input, ufw staus is "inactive" and i don't have apache installed hence no /etc/apache2 folder... still the problem persists... and again on the server when i do lynx 127.0.0.1, all is well and works fine
– Holger Will
Sep 20 '15 at 22:03
nginx
is listening on port 80..check thenginx
logs..
– heemayl
Sep 20 '15 at 22:03
1
1
Please edit your question and add the output of
sudo netstat -tlpn
running from the server..– heemayl
Sep 20 '15 at 21:48
Please edit your question and add the output of
sudo netstat -tlpn
running from the server..– heemayl
Sep 20 '15 at 21:48
Ubuntu and debian usually use ufw (uncomplicated firewall) and, oftentimes, the default is to block incoming and allow outgoing. Have you tried running
sudo ufw disable
on the server machine to see if that is the culprit? Additionally, you may need to set access by properly editing your /etc/apache2/sites-enabled
file.– mchid
Sep 20 '15 at 21:55
Ubuntu and debian usually use ufw (uncomplicated firewall) and, oftentimes, the default is to block incoming and allow outgoing. Have you tried running
sudo ufw disable
on the server machine to see if that is the culprit? Additionally, you may need to set access by properly editing your /etc/apache2/sites-enabled
file.– mchid
Sep 20 '15 at 21:55
Some ISPs and routers block port 80 access, keep that in mind. Is this on an offsite server or...?
– Thomas Ward♦
Sep 20 '15 at 21:58
Some ISPs and routers block port 80 access, keep that in mind. Is this on an offsite server or...?
– Thomas Ward♦
Sep 20 '15 at 21:58
thanks for your input, ufw staus is "inactive" and i don't have apache installed hence no /etc/apache2 folder... still the problem persists... and again on the server when i do lynx 127.0.0.1, all is well and works fine
– Holger Will
Sep 20 '15 at 22:03
thanks for your input, ufw staus is "inactive" and i don't have apache installed hence no /etc/apache2 folder... still the problem persists... and again on the server when i do lynx 127.0.0.1, all is well and works fine
– Holger Will
Sep 20 '15 at 22:03
nginx
is listening on port 80..check the nginx
logs..– heemayl
Sep 20 '15 at 22:03
nginx
is listening on port 80..check the nginx
logs..– heemayl
Sep 20 '15 at 22:03
|
show 2 more comments
3 Answers
3
active
oldest
votes
i did a tcptraceroute 87.106.64.11 80
and its definitely my server that is blocking the port. At some point in the trace i got this:
s18132051.onlinehome-server.info (87.106.64.11) [closed]
So i reset my ip tables, and that did the trick.
So either there where some hidden rule in the table, or iptable -L
did not give me all rules. I will mark this as the answer as it fixes the problem.
I would still love to hear, how come i didn't get any blocking rules when doing iptables -L
add a comment |
I experienced the same problem, but on Debian 8.4 (Jessie). Like the above, the solution was the IPTables flush script as listed at http://insanelabs.net/linux/linux-reset-iptables-firewall-rules/. Though iptables reported no rules, there must have been some "hidden" rules, or otherwise a bug in iptables itself. I am reporting this bug to the Debian maintainers.
In case the linked site goes down, here is the full text of the script in question, reproduced here for convenience.
#!/bin/sh
echo "Flushing iptables rules..."
sleep 1
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
add a comment |
You didn't list all of your rules. I've found a good way to get any active netfilter tables is:
for blah in sudo /bin/cat /proc/net/ip_tables_names
; do sudo /sbin/iptables -t $blah -L -vn --line-numbers|sed "s/^/$blah: /" ; done |less -RXF
Another options is to run:
/sbin/iptables-save
If you have the patience, you can go through each rule one at a time and change any DENY targets to ACCEPT and see which one fixes the problem.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f676434%2fport-80-connection-refused%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
i did a tcptraceroute 87.106.64.11 80
and its definitely my server that is blocking the port. At some point in the trace i got this:
s18132051.onlinehome-server.info (87.106.64.11) [closed]
So i reset my ip tables, and that did the trick.
So either there where some hidden rule in the table, or iptable -L
did not give me all rules. I will mark this as the answer as it fixes the problem.
I would still love to hear, how come i didn't get any blocking rules when doing iptables -L
add a comment |
i did a tcptraceroute 87.106.64.11 80
and its definitely my server that is blocking the port. At some point in the trace i got this:
s18132051.onlinehome-server.info (87.106.64.11) [closed]
So i reset my ip tables, and that did the trick.
So either there where some hidden rule in the table, or iptable -L
did not give me all rules. I will mark this as the answer as it fixes the problem.
I would still love to hear, how come i didn't get any blocking rules when doing iptables -L
add a comment |
i did a tcptraceroute 87.106.64.11 80
and its definitely my server that is blocking the port. At some point in the trace i got this:
s18132051.onlinehome-server.info (87.106.64.11) [closed]
So i reset my ip tables, and that did the trick.
So either there where some hidden rule in the table, or iptable -L
did not give me all rules. I will mark this as the answer as it fixes the problem.
I would still love to hear, how come i didn't get any blocking rules when doing iptables -L
i did a tcptraceroute 87.106.64.11 80
and its definitely my server that is blocking the port. At some point in the trace i got this:
s18132051.onlinehome-server.info (87.106.64.11) [closed]
So i reset my ip tables, and that did the trick.
So either there where some hidden rule in the table, or iptable -L
did not give me all rules. I will mark this as the answer as it fixes the problem.
I would still love to hear, how come i didn't get any blocking rules when doing iptables -L
edited Apr 2 '16 at 20:50
Jeremy
32
32
answered Sep 21 '15 at 3:17
Holger WillHolger Will
181119
181119
add a comment |
add a comment |
I experienced the same problem, but on Debian 8.4 (Jessie). Like the above, the solution was the IPTables flush script as listed at http://insanelabs.net/linux/linux-reset-iptables-firewall-rules/. Though iptables reported no rules, there must have been some "hidden" rules, or otherwise a bug in iptables itself. I am reporting this bug to the Debian maintainers.
In case the linked site goes down, here is the full text of the script in question, reproduced here for convenience.
#!/bin/sh
echo "Flushing iptables rules..."
sleep 1
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
add a comment |
I experienced the same problem, but on Debian 8.4 (Jessie). Like the above, the solution was the IPTables flush script as listed at http://insanelabs.net/linux/linux-reset-iptables-firewall-rules/. Though iptables reported no rules, there must have been some "hidden" rules, or otherwise a bug in iptables itself. I am reporting this bug to the Debian maintainers.
In case the linked site goes down, here is the full text of the script in question, reproduced here for convenience.
#!/bin/sh
echo "Flushing iptables rules..."
sleep 1
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
add a comment |
I experienced the same problem, but on Debian 8.4 (Jessie). Like the above, the solution was the IPTables flush script as listed at http://insanelabs.net/linux/linux-reset-iptables-firewall-rules/. Though iptables reported no rules, there must have been some "hidden" rules, or otherwise a bug in iptables itself. I am reporting this bug to the Debian maintainers.
In case the linked site goes down, here is the full text of the script in question, reproduced here for convenience.
#!/bin/sh
echo "Flushing iptables rules..."
sleep 1
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
I experienced the same problem, but on Debian 8.4 (Jessie). Like the above, the solution was the IPTables flush script as listed at http://insanelabs.net/linux/linux-reset-iptables-firewall-rules/. Though iptables reported no rules, there must have been some "hidden" rules, or otherwise a bug in iptables itself. I am reporting this bug to the Debian maintainers.
In case the linked site goes down, here is the full text of the script in question, reproduced here for convenience.
#!/bin/sh
echo "Flushing iptables rules..."
sleep 1
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
answered Jun 22 '16 at 6:56
JessicaJessica
211
211
add a comment |
add a comment |
You didn't list all of your rules. I've found a good way to get any active netfilter tables is:
for blah in sudo /bin/cat /proc/net/ip_tables_names
; do sudo /sbin/iptables -t $blah -L -vn --line-numbers|sed "s/^/$blah: /" ; done |less -RXF
Another options is to run:
/sbin/iptables-save
If you have the patience, you can go through each rule one at a time and change any DENY targets to ACCEPT and see which one fixes the problem.
add a comment |
You didn't list all of your rules. I've found a good way to get any active netfilter tables is:
for blah in sudo /bin/cat /proc/net/ip_tables_names
; do sudo /sbin/iptables -t $blah -L -vn --line-numbers|sed "s/^/$blah: /" ; done |less -RXF
Another options is to run:
/sbin/iptables-save
If you have the patience, you can go through each rule one at a time and change any DENY targets to ACCEPT and see which one fixes the problem.
add a comment |
You didn't list all of your rules. I've found a good way to get any active netfilter tables is:
for blah in sudo /bin/cat /proc/net/ip_tables_names
; do sudo /sbin/iptables -t $blah -L -vn --line-numbers|sed "s/^/$blah: /" ; done |less -RXF
Another options is to run:
/sbin/iptables-save
If you have the patience, you can go through each rule one at a time and change any DENY targets to ACCEPT and see which one fixes the problem.
You didn't list all of your rules. I've found a good way to get any active netfilter tables is:
for blah in sudo /bin/cat /proc/net/ip_tables_names
; do sudo /sbin/iptables -t $blah -L -vn --line-numbers|sed "s/^/$blah: /" ; done |less -RXF
Another options is to run:
/sbin/iptables-save
If you have the patience, you can go through each rule one at a time and change any DENY targets to ACCEPT and see which one fixes the problem.
answered Jan 19 at 14:27
LeeLee
113
113
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f676434%2fport-80-connection-refused%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Please edit your question and add the output of
sudo netstat -tlpn
running from the server..– heemayl
Sep 20 '15 at 21:48
Ubuntu and debian usually use ufw (uncomplicated firewall) and, oftentimes, the default is to block incoming and allow outgoing. Have you tried running
sudo ufw disable
on the server machine to see if that is the culprit? Additionally, you may need to set access by properly editing your/etc/apache2/sites-enabled
file.– mchid
Sep 20 '15 at 21:55
Some ISPs and routers block port 80 access, keep that in mind. Is this on an offsite server or...?
– Thomas Ward♦
Sep 20 '15 at 21:58
thanks for your input, ufw staus is "inactive" and i don't have apache installed hence no /etc/apache2 folder... still the problem persists... and again on the server when i do lynx 127.0.0.1, all is well and works fine
– Holger Will
Sep 20 '15 at 22:03
nginx
is listening on port 80..check thenginx
logs..– heemayl
Sep 20 '15 at 22:03