Как эффективно отладить проблему HTTP-запроса на моем веб-сервере?

Question

У меня странная проблема с моим веб-сервером в локальной сети. HTTP-запросы вращаются вечно, но не дают значимого кода ошибки.

Эта проблема возникает на моем маршрутизаторе ASUS и маршрутизаторе Cisco, но, как это ни парадоксально, на моем старом маршрутизаторе DLink это не происходит. Некоторый анализ различий ниже.

[Обновление 19 февраля, 22:30] Я попытался переключиться с Apache на сервер Nginx (основываясь на комментариях Кевина), и они показали идентичный результат. Похоже, что проблемы с пакетами TCP не зависят от сервера (см. Tcpdumps ниже). Я также экспериментировал с размером TCP-datapush и обнаружил, что вероятность сбоя уменьшается с размером запроса. Когда меньше чем ~ 800 байт, ему удается загрузить примерно половину времени после зацикливания 5-10 до получения этого редкого ACK. При ~ 2000 байтах это редко, но иногда работает. На ~ 6000 байтов, никак. Маршрутизатор DLink работает мгновенно на любом из этих размеров файлов. Я проверил, нет ли каких-либо мешающих пакетов на интерфейсе обратной связи, ничего там. Я переключил кабели / порты (но не сетевые карты, только один).

Я попытался использовать telnet для выполнения ручного HTTP-запроса для простой страницы:

telnet 192.168.0.101 80
GET /index.html HTTP/1.0

Та же самая проблема появляется там, висящая в течение нескольких секунд.

Выход Netstat:

simon@fire:~$ sudo netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1056/sshd       
tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN      1147/xinetd     
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      1482/sendmail: MTA:
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      1064/mysqld
tcp        0      0 127.0.0.1:587           0.0.0.0:*               LISTEN         1482/sendmail: MTA:
tcp6       0      0 :::21                   :::*                    LISTEN      1066/vsftpd     
tcp6       0      0 :::22                   :::*                    LISTEN      1056/sshd       
tcp6       0      0 :::80                   :::*                    LISTEN      1234/apache2

Выключение Apache и попытка netcat работает сразу через один и тот же порт:

simon@fire:~$ sudo service apache2 stop
simon@fire:~$ { echo -ne "HTTP/1.0 200 OK\r\nContent-Length: 13\r\n\r\n"; echo "Hello World!"; } | sudo nc -l 80
GET / HTTP/1.1
Host: 192.168.0.101
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0
(On client --> Works immediately)

Дамп tcpdump, похоже, указывает на отсутствующий пакет "ACK 2921", следующий за Push-пакетом. Затем сервер повторяет пакет Push, по-прежнему без подтверждения. Затем он выполняет серию последовательных ACK 1:1461 перед завершающим F-пакетом, похоже, сдаваясь.

Я не эксперт по пакетам tcp, но это от анализа сбойного случая (маршрутизатор ASUS) по сравнению с успешным случаем (маршрутизатор Dlink). На DLink есть чистый пакет ACK 2921. До этого оба показывают одинаковый вывод.

Одно очевидное отличие состоит в том, что с DLink сервер видит клиента по его IP (192.168.0.104), тогда как на ASUS сервер видит клиента по его имени хоста (Gin) - но экспериментирует с правилами третьего маршрутизатора (Cisco) это является частью проблемы, поскольку он также видит клиента по IP, но в остальном ведет себя так же, как ASUS.

simon@fire:~$ sudo tcpdump -i eth0 port 80 or port 443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

19:43:37.815448 IP Gin.60309 > fire.http: Flags [S], seq 4284943091, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
19:43:37.815490 IP fire.http > Gin.60309: Flags [S.], seq 1854464822, ack 4284943092, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
19:43:37.815684 IP Gin.60309 > fire.http: Flags [.], ack 1, win 16425, length 0
19:43:37.816701 IP Gin.60309 > fire.http: Flags [P.], seq 1:344, ack 1, win 16425, length 343: HTTP: GET / HTTP/1.1
19:43:37.816729 IP fire.http > Gin.60309: Flags [.], ack 344, win 237, length 0
19:43:37.818341 IP fire.http > Gin.60309: Flags [.], seq 1:2921, ack 344, win 237, length 2920: HTTP: HTTP/1.1 200 OK
19:43:37.818357 IP fire.http > Gin.60309: Flags [P.], seq 2921:4155, ack 344, win 237, length 1234: HTTP

-- There seems to be a missing [.] ack 2921 packet here!? Then the server tries again --

19:43:37.827311 IP fire.http > Gin.60309: Flags [P.], seq 2921:4155, ack 344, win 237, length 1234: HTTP
19:43:38.051329 IP fire.http > Gin.60309: Flags [.], seq 1:1461, ack 344, win 237, length 1460: HTTP: HTTP/1.1 200 OK
19:43:38.499322 IP fire.http > Gin.60309: Flags [.], seq 1:1461, ack 344, win 237, length 1460: HTTP: HTTP/1.1 200 OK
19:43:39.395318 IP fire.http > Gin.60309: Flags [.], seq 1:1461, ack 344, win 237, length 1460: HTTP: HTTP/1.1 200 OK
19:43:41.191327 IP fire.http > Gin.60309: Flags [.], seq 1:1461, ack 344, win 237, length 1460: HTTP: HTTP/1.1 200 OK
19:43:42.823524 IP fire.http > Gin.60309: Flags [F.], seq 4155, ack 344, win 237, length 0
19:43:42.823736 IP Gin.60309 > fire.http: Flags [.], ack 1, win 16425, length 0
19:43:44.783318 IP fire.http > Gin.60309: Flags [.], seq 1:1461, ack 344, win 237, length 1460: HTTP: HTTP/1.1 200 OK
19:43:51.967338 IP fire.http > Gin.60309: Flags [.], seq 1:1461, ack 344, win 237, length 1460: HTTP: HTTP/1.1 200 OK
19:43:52.825832 IP Gin.60309 > fire.http: Flags [.], seq 343:344, ack 1, win 16425, length 1: HTTP
19:43:52.825875 IP fire.http > Gin.60309: Flags [.], ack 344, win 237, options [nop,nop,sack 1 {343:344}], length 0
19:44:02.826426 IP Gin.60309 > fire.http: Flags [.], seq 343:344, ack 1, win 16425, length 1: HTTP
19:44:02.826464 IP fire.http > Gin.60309: Flags [.], ack 344, win 237, options [nop,nop,sack 1 {343:344}], length 0
19:44:06.335330 IP fire.http > Gin.60309: Flags [.], seq 1:1461, ack 344, win 237, length 1460: HTTP: HTTP/1.1 200 OK
19:44:12.827029 IP Gin.60309 > fire.http: Flags [.], seq 343:344, ack 1, win 16425, length 1: HTTP
19:44:12.827067 IP fire.http > Gin.60309: Flags [.], ack 344, win 237, options [nop,nop,sack 1 {343:344}], length 0
19:44:22.827563 IP Gin.60309 > fire.http: Flags [.], seq 343:344, ack 1, win 16425, length 1: HTTP
19:44:22.827592 IP fire.http > Gin.60309: Flags [.], ack 344, win 237, options [nop,nop,sack 1 {343:344}], length 0
19:44:32.828133 IP Gin.60309 > fire.http: Flags [.], seq 343:344, ack 1, win 16425, length 1: HTTP
19:44:32.828157 IP fire.http > Gin.60309: Flags [.], ack 344, win 237, options [nop,nop,sack 1 {343:344}], length 0
19:44:35.039322 IP fire.http > Gin.60309: Flags [.], seq 1:1461, ack 344, win 237, length 1460: HTTP: HTTP/1.1 200 OK
19:44:42.828692 IP Gin.60309 > fire.http: Flags [.], seq 343:344, ack 1, win 16425, length 1: HTTP
19:44:42.828734 IP fire.http > Gin.60309: Flags [.], ack 344, win 237, options [nop,nop,sack 1 {343:344}], length 0
19:45:08.571555 IP Gin.60309 > fire.http: Flags [F.], seq 344, ack 1, win 16425, length 0
19:45:08.571581 IP fire.http > Gin.60309: Flags [.], ack 345, win 237, length 0

(Pressed CTRL C after 30 seconds)
^C
32 packets captured
32 packets received by filter
0 packets dropped by kernel

Tcpdump при использовании роутера DLink (работает нормально) ниже:

simon@fire:/sbin$ sudo tcpdump -B 4096 -i eth0 port 80 or port 443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:48:20.209920 IP 192.168.0.104.53696 > fire.http: Flags [S], seq 1043812686, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
21:48:20.209954 IP fire.http > 192.168.0.104.53696: Flags [S.], seq 639467520, ack 1043812687, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
21:48:20.210290 IP 192.168.0.104.53696 > fire.http: Flags [.], ack 1, win 16425, length 0
21:48:20.211575 IP 192.168.0.104.53696 > fire.http: Flags [P.], seq 1:344, ack 1, win 16425, length 343: HTTP: GET / HTTP/1.1
21:48:20.211603 IP fire.http > 192.168.0.104.53696: Flags [.], ack 344, win 237, length 0
21:48:20.213190 IP fire.http > 192.168.0.104.53696: Flags [.], seq 1:2921, ack 344, win 237, length 2920: HTTP: HTTP/1.1 200 OK
21:48:20.213199 IP fire.http > 192.168.0.104.53696: Flags [P.], seq 2921:4155, ack 344, win 237, length 1234: HTTP
21:48:20.213959 IP 192.168.0.104.53696 > fire.http: Flags [.], ack 2921, win 16425, length 0
21:48:20.415317 IP fire.http > 192.168.0.104.53696: Flags [P.], seq 2921:4155, ack 344, win 237, length 1234: HTTP
21:48:20.416066 IP 192.168.0.104.53696 > fire.http: Flags [.], ack 4155, win 16116, options [nop,nop,sack 1 {2921:4155}], length 0
21:48:25.215387 IP fire.http > 192.168.0.104.53696: Flags [F.], seq 4155, ack 344, win 237, length 0
21:48:25.215864 IP 192.168.0.104.53696 > fire.http: Flags [.], ack 4156, win 16116, length 0
21:48:25.216086 IP 192.168.0.104.53696 > fire.http: Flags [F.], seq 344, ack 4156, win 16116, length 0
21:48:25.216093 IP fire.http > 192.168.0.104.53696: Flags [.], ack 345, win 237, length 0
^C
14 packets captured
14 packets received by filter
0 packets dropped by kernel

Я также проверил брандмауэр, не обнаружил пакетов, соответствующих правилам "Запретить", а также выполнил рекомендованную команду iptables, но это не помогло:/sbin/iptables -I INPUT -p tcp --dport 80 -j ПРИНЯТЬ

вывод ifconfig:

eth0  Link encap:Ethernet  HWaddr 00:16:e6:85:ad:a1  
      inet addr:192.168.0.101  Bcast:192.168.0.255  Mask:255.255.255.0
      inet6 addr: fe80::216:e6ff:fe85:ada1/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:4660 errors:0 dropped:2 overruns:0 frame:0
      TX packets:1769 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:399847 (399.8 KB)  TX bytes:210999 (210.9 KB)
      Interrupt:17 

lo    Link encap:Local Loopback  
      inet addr:127.0.0.1  Mask:255.0.0.0
      inet6 addr: ::1/128 Scope:Host
      UP LOOPBACK RUNNING  MTU:65536  Metric:1
      RX packets:47 errors:0 dropped:0 overruns:0 frame:0
      TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:0 
      RX bytes:15869 (15.8 KB)  TX bytes:15869 (15.8 KB)

вывод iptables:

~$ sudo iptables -L -n
Chain INPUT (policy DROP)
target     prot opt source               destination         
f2b-sshd   tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22
ufw-before-logging-input  all  --  0.0.0.0/0            0.0.0.0/0           
ufw-before-input  all  --  0.0.0.0/0            0.0.0.0/0           
ufw-after-input  all  --  0.0.0.0/0            0.0.0.0/0           
ufw-after-logging-input  all  --  0.0.0.0/0            0.0.0.0/0           
ufw-reject-input  all  --  0.0.0.0/0            0.0.0.0/0           
ufw-track-input  all  --  0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy DROP)
target     prot opt source               destination         
ufw-before-logging-forward  all  --  0.0.0.0/0            0.0.0.0/0           
ufw-before-forward  all  --  0.0.0.0/0            0.0.0.0/0           
ufw-after-forward  all  --  0.0.0.0/0            0.0.0.0/0           
ufw-after-logging-forward  all  --  0.0.0.0/0            0.0.0.0/0           
ufw-reject-forward  all  --  0.0.0.0/0            0.0.0.0/0           
ufw-track-forward  all  --  0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ufw-before-logging-output  all  --  0.0.0.0/0            0.0.0.0/0           
ufw-before-output  all  --  0.0.0.0/0            0.0.0.0/0           
ufw-after-output  all  --  0.0.0.0/0            0.0.0.0/0           
ufw-after-logging-output  all  --  0.0.0.0/0            0.0.0.0/0           
ufw-reject-output  all  --  0.0.0.0/0            0.0.0.0/0           
ufw-track-output  all  --  0.0.0.0/0            0.0.0.0/0           

Chain f2b-sshd (1 references)
target     prot opt source               destination         
RETURN     all  --  0.0.0.0/0            0.0.0.0/0           

Chain ufw-after-forward (1 references)
target     prot opt source               destination         

Chain ufw-after-input (1 references)
target     prot opt source               destination         
ufw-skip-to-policy-input  udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:137
ufw-skip-to-policy-input  udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:138
ufw-skip-to-policy-input  tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:139
ufw-skip-to-policy-input  tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:445
ufw-skip-to-policy-input  udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:67
ufw-skip-to-policy-input  udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:68
ufw-skip-to-policy-input  all  --  0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type BROADCAST

Chain ufw-after-logging-forward (1 references)
target     prot opt source               destination         
LOG        all  --  0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW BLOCK] "

Chain ufw-after-logging-input (1 references)
target     prot opt source               destination         
LOG        all  --  0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW BLOCK] "

Chain ufw-after-logging-output (1 references)
target     prot opt source               destination         

Chain ufw-after-output (1 references)
target     prot opt source               destination         

Chain ufw-before-forward (1 references)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 3
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 4
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 11
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 12
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 8
ufw-user-forward  all  --  0.0.0.0/0            0.0.0.0/0           

Chain ufw-before-input (1 references)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
ufw-logging-deny  all  --  0.0.0.0/0            0.0.0.0/0            ctstate INVALID
DROP       all  --  0.0.0.0/0            0.0.0.0/0            ctstate INVALID
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 3
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 4
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 11
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 12
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 8
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68
ufw-not-local  all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     udp  --  0.0.0.0/0            224.0.0.251          udp dpt:5353
ACCEPT     udp  --  0.0.0.0/0            239.255.255.250      udp dpt:1900
ufw-user-input  all  --  0.0.0.0/0            0.0.0.0/0           

Chain ufw-before-logging-forward (1 references)
target     prot opt source               destination         

Chain ufw-before-logging-input (1 references)
target     prot opt source               destination         

Chain ufw-before-logging-output (1 references)
target     prot opt source               destination         

Chain ufw-before-output (1 references)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
ufw-user-output  all  --  0.0.0.0/0            0.0.0.0/0           

Chain ufw-logging-allow (0 references)
target     prot opt source               destination         
LOG        all  --  0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW ALLOW] "

Chain ufw-logging-deny (2 references)
target     prot opt source               destination         
RETURN     all  --  0.0.0.0/0            0.0.0.0/0            ctstate INVALID limit: avg 3/min burst 10
LOG        all  --  0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW BLOCK] "

Chain ufw-not-local (1 references)
target     prot opt source               destination         
RETURN     all  --  0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL
RETURN     all  --  0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type MULTICAST
RETURN     all  --  0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type BROADCAST
ufw-logging-deny  all  --  0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 10
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain ufw-reject-forward (1 references)
target     prot opt source               destination         

Chain ufw-reject-input (1 references)
target     prot opt source               destination         

Chain ufw-reject-output (1 references)
target     prot opt source               destination         

Chain ufw-skip-to-policy-forward (0 references)
target     prot opt source               destination         
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain ufw-skip-to-policy-input (7 references)
target     prot opt source               destination         
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain ufw-skip-to-policy-output (0 references)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           

Chain ufw-track-forward (1 references)
target     prot opt source               destination         

Chain ufw-track-input (1 references)
target     prot opt source               destination         

Chain ufw-track-output (1 references)
target     prot opt source               destination         
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            ctstate NEW
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            ctstate NEW

Chain ufw-user-forward (1 references)
target     prot opt source               destination         

Chain ufw-user-input (1 references)
target     prot opt source               destination         
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 80,443 /* 'dapp_Nginx%20Full' */
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80 /* 'dapp_Nginx%20HTTP' */

Chain ufw-user-limit (0 references)
target     prot opt source               destination         
LOG        all  --  0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 5 LOG flags 0 level 4 prefix "[UFW LIMIT BLOCK] "
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

Chain ufw-user-limit-accept (0 references)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           

Chain ufw-user-logging-forward (0 references)
target     prot opt source               destination         

Chain ufw-user-logging-input (0 references)
target     prot opt source               destination         

Chain ufw-user-logging-output (0 references)
target     prot opt source               destination         

Chain ufw-user-output (1 references)
target     prot opt source               destination

Аналогичная проблема возникает, если я пытаюсь получить доступ к Интернету с сервера через порт 80 (очень медленно, крутится или иногда может загрузить простую страницу через очень долгое время).

Это сервер LAMP (Ubuntu 16.4).

Заранее спасибо!

score 1 · Answer 1 · 2011-03-09T19:38:42

Вы пробовали запустить tcpdump на сервере?

sudo tcpdump -i eth0 port 80 or port 443

Если вы не видите пакеты, вам может потребоваться дважды проверить брандмауэр.

Вы также можете отключить Apache и запустить временный веб-сервер Netcat на порт 80 с

{ echo -ne "HTTP/1.0 200 OK\r\nContent-Length: 13\r\n\r\n"; echo "Hello World!"; } | sudo nc -l 80

Редактировать:

Вы можете использовать tcpdump для записи в файл, а затем передать и открыть его на клиентском компьютере с wireshark, чтобы увидеть, какая информация передается в пакетах.

sudo tcpdump -i eth0 port 80 or port 443 -w httpdebug.pcap

Затем скопируйте этот файл на компьютер с wireshark. Если вам нужно установить wireshark на машине с Windows, вы можете пропустить установку winpcap.

Некоторые другие шаги, которые вы можете попробовать:

При использовании apache файл с надписью "Hello World!""или что-то очень короткое в этом.
Использование веб-сервера netcat для размещения вашего index.html

{ echo -ne "HTTP/1.0 200 OK\r\nContent-Length: $(wc -c <index.html)\r\n\r\n"; cat index.html; } | sudo nc -l 80

Если последнее работает, то может быть либо много контента, блокирующего рендеринг, либо некоторая неверная конфигурация в apache. Я бы попробовал очистить и переустановить apache, а не искать проблему с конфигурацией.

score 0 · Answer 2 · 2011-03-09T19:38:42

Согласно sudo netstat -lntp , настройки вашего apache не прослушивают IPv4.

Вам необходимо добавить в конфигурацию вашего apache:

#NameVirtualHost *:80
Listen 0.0.0.0:80

Если вы используете протокол SSL на своем сайте, добавьте также:

<IfModule ssl_module>
#   NameVirtualHost *:443
    Listen 0.0.0.0:443
</IfModule>

<IfModule mod_gnutls.c>
#   NameVirtualHost *:443
    Listen 0.0.0.0:443
</IfModule>

Эти настройки применяются к версиям Apache 2.4 +. Если вы используете версии 2.2, то добавьте также

NameVirtualHost *:80
NameVirtualHost *:443

в (apache|httpd|ports)\.conf

Сейчас выбран русский

Как эффективно отладить проблему HTTP-запроса на моем веб-сервере?

2 ответа2

Всё ещё ищете ответ? Посмотрите другие вопросы с метками apache-http-server http ubuntu-16.04 lamp.

Как эффективно отладить проблему HTTP-запроса на моем веб-сервере?

2 ответа2

Всё ещё ищете ответ? Посмотрите другие вопросы с метками apache-http-server http ubuntu-16.04 lamp.

Похожие