ERR_CONNECTION_REFUSED หมายถึงเบราว์เซอร์ไปถึงเครื่องที่ปลายทางแล้ว และเครื่องนั้นส่งคำปฏิเสธกลับมาชัด ๆ ไม่ใช่เงียบหาย แต่เป็นคำตอบจริง และคำตอบคือไม่
ความต่างข้อนี้สำคัญมากก่อนจะเริ่มแก้ เพราะมันตัดความเป็นไปได้ออกไปเยอะทันที คือ DNS แปลชื่อสำเร็จแล้ว เส้นทางเน็ตเดินถึง มีอะไรมีชีวิตอยู่ที่ IP นั้นจริง ปัญหาจึงแคบลงมาก เหลือแค่ว่าไม่มีบริการไหนเปิดรออยู่บนพอร์ตที่ขอ หรือมีอะไรตั้งใจปฏิเสธเราอยู่
เทียบกับ ERR_CONNECTION_TIMED_OUT ที่แพ็กเก็ตหายไปเฉย ๆ และสาเหตุอยู่ได้ทุกจุดตั้งแต่เราเตอร์บ้านเราไปจนถึงเซิร์ฟเวอร์ — ตัว refused วินิจฉัยง่ายกว่ามาก บทความนี้ไล่ตามรายการสั้น ๆ นั้น
refused, timed out, reset — สามตัวนี้ไม่เหมือนกัน
สามตัวนี้มักถูกเหมารวมว่า "เว็บพัง" แต่แต่ละตัวบอกเจาะจงว่าพังตรงจุดไหนของเส้นทาง
| error | เกิดอะไรขึ้นในระดับเน็ตเวิร์ก | ตัดอะไรออกได้ |
|---|---|---|
| ERR_CONNECTION_REFUSED | เซิร์ฟเวอร์ส่ง TCP RST กลับ — ปฏิเสธแบบตั้งใจ | DNS เส้นทาง และการเข้าถึงเครื่อง ปกติทั้งหมด |
| ERR_CONNECTION_TIMED_OUT | ไม่มีคำตอบเลย แพ็กเก็ตถูกทิ้งเงียบ ๆ | ตัดอะไรไม่ได้ — พังได้ทุกจุดในเส้นทาง |
| ERR_CONNECTION_RESET | ต่อติดแล้วถูกตัดกลางทาง | การต่อครั้งแรกสำเร็จ มีอะไรมาตัดทีหลัง |
| DNS_PROBE_FINISHED_NXDOMAIN | ชื่อโดเมนแปลไม่ออกเป็น IP | ทุกอย่างหลัง DNS — ยังไปไม่ถึงขั้นนั้น |
สาเหตุที่เจอบ่อย เรียงจากมากไปน้อย
- ไม่มีอะไรเปิดรออยู่บนพอร์ตนั้น เว็บเซิร์ฟเวอร์ล่ม ถูกสั่งหยุด หรือไม่ได้ขึ้นเองหลังรีบูต — อันนี้เป็นสาเหตุอันดับหนึ่งเวลาเราเป็นเจ้าของเว็บ
- เรียกผิดพอร์ต เช่นเรียก https:// ไปที่เครื่องที่เปิดแต่ HTTP ธรรมดา หรือต่อไป dev server พอร์ต 3000 ที่ปิดไปแล้ว
- ไฟร์วอลล์ตั้งเป็น REJECT ไม่ใช่ DROP ทั้งสองแบบบล็อกเหมือนกัน แต่ REJECT ส่งคำปฏิเสธกลับมาซึ่งทำให้เกิด error ตัวนี้พอดี
- บริการ bind อยู่แค่ localhost เจอบ่อยมากกับเครื่องที่เพิ่งตั้งค่าใหม่และฐานข้อมูล — โปรเซสรันอยู่จริง แต่รับเฉพาะการเชื่อมต่อจากในเครื่องตัวเอง
- ตั้งค่า proxy หรือส่วนขยายเบราว์เซอร์ผิด VPN หรือ extension ที่ชี้ไป proxy ที่ไม่ได้เปิดอยู่ จะทำให้ทุกการเชื่อมต่อถูกปฏิเสธ
- โปรแกรมในเครื่องบล็อกอยู่ — แอนตี้ไวรัส โปรแกรมของบริษัท หรือตัวควบคุมการเข้าเว็บ ปฏิเสธการต่อออกไปยังปลายทางนั้น
- เว็บย้ายหรือปิดไปจริง ๆ แล้วมีอะไรอย่างอื่นมารับสายที่ IP นั้นแทน
ก่อนอื่น: เจอคนเดียวหรือเจอทุกคน
สองนาทีตรงนี้ช่วยประหยัดเวลาเป็นชั่วโมงจากการไปแก้เซิร์ฟเวอร์ที่ไม่เคยพัง
- เปิดเว็บด้วยเน็ตมือถือโดยปิด Wi-Fi ถ้าเข้าได้ แปลว่าเซิร์ฟเวอร์ปกติ ปัญหาอยู่ที่เน็ต เครื่อง หรือเบราว์เซอร์ของเรา
- ลองหน้าต่างไม่ระบุตัวตน แล้วลองเบราว์เซอร์อื่น เพื่อตัดส่วนขยายและค่า proxy ที่จำไว้ออกจากรายการต้องสงสัย
- ใช้เครื่องมือเช็ก "down for everyone" ตัวไหนก็ได้ มันเข้าจากเซิร์ฟเวอร์ข้างนอกและให้คำตอบที่เป็นกลาง
- ลองเว็บเดียวกันจากอีกเครื่องในวงเน็ตเดียวกัน ถ้าทุกเครื่องเข้าไม่ได้แต่เน็ตมือถือเข้าได้ ปัญหาอยู่ที่เราเตอร์หรือการกรองของผู้ให้บริการเน็ต
ถ้าเป็นผู้ใช้ทั่วไป — แก้ตามลำดับนี้
- เช็กว่าที่อยู่ถูกต้อง รวมถึงโปรโตคอล บางเครื่องเปิดแต่ HTTP และจะปฏิเสธ HTTPS ตรง ๆ หรือกลับกัน
- ปิด VPN หรือส่วนขยาย proxy แล้วลองใหม่ ถ้าตั้ง proxy ไว้แต่ตัวโปรแกรม proxy ไม่ได้เปิด ทุกการเชื่อมต่อจะถูกปฏิเสธ
- เช็กค่า proxy ของระบบ บน Windows ดูใน Internet Options บน macOS ดูใน Network settings ลบอะไรที่เราไม่ได้ตั้งเองออก
- ล้างแคชเบราว์เซอร์และแคช DNS บน macOS ใช้ "sudo dscacheutil -flushcache" บน Windows ใช้ "ipconfig /flushdns"
- ปิดฟีเจอร์ป้องกันเว็บของแอนตี้ไวรัสชั่วคราว บางตัวปฏิเสธการต่อไปยังปลายทางในบัญชีดำโดยไม่บอกให้ชัด
- รีสตาร์ตเราเตอร์ เพื่อล้างสถานะ NAT ค้างที่บางครั้งทำให้ต่อไปปลายทางหนึ่งไม่ได้
- ถ้าทำทุกอย่างแล้วยังไม่ได้ แต่คนอื่นเข้าได้ ผู้ให้บริการเน็ตอาจกรองอยู่ ลองด้วยเน็ตมือถือเพื่อยืนยันก่อนเสียเวลาต่อ
ถ้าเป็นเจ้าของเว็บ — ส่วนวินิจฉัยที่สำคัญที่สุด
เมื่อเราคุมเซิร์ฟเวอร์เอง error ตัวนี้เป็นตัวที่ตามง่ายที่สุดตัวหนึ่ง เพราะมันชี้ไปที่คำถามเดียวที่เจาะจงมาก คือมีอะไรเปิดรออยู่บนพอร์ตนั้นไหม และมันรับการเชื่อมต่อจากข้างนอกหรือเปล่า
- เช็กว่าบริการรันอยู่ไหม: "systemctl status nginx" หรือ "systemctl status apache2" ถ้าหยุดอยู่ให้สั่งเริ่ม แล้วไปอ่าน log ว่าทำไมมันหยุด เพราะเดี๋ยวมันจะหยุดอีก
- ดูว่าอะไรเปิดรออยู่จริง ๆ: "ss -tlnp" (หรือ "netstat -tlnp") นี่คือคำสั่งที่ให้ข้อมูลมากที่สุดสำหรับ error ตัวนี้ เราต้องเห็นเว็บเซิร์ฟเวอร์ bind อยู่ที่พอร์ต 80 และ 443
- ดูที่อยู่ bind ในผลลัพธ์นั้น ถ้าเป็น "127.0.0.1:80" แปลว่าบริการรับแต่การเชื่อมต่อจากในเครื่องและจะปฏิเสธคนอื่นทั้งหมด ต้องเป็น "0.0.0.0:80" หรือ IP สาธารณะของเรา
- เช็กไฟร์วอลล์ ถ้าใช้ ufw สั่ง "ufw status" ถ้าใช้ firewalld สั่ง "firewall-cmd --list-all" และถ้าเป็น VPS ต้องเช็กไฟร์วอลล์ระดับเน็ตเวิร์กของผู้ให้บริการด้วย ซึ่งแยกจากตัวบนเครื่อง
- ยืนยันจากนอกเซิร์ฟเวอร์ สั่ง "curl -I https://เว็บของคุณ.com/" จากอีกเครื่อง หรือ "telnet เว็บของคุณ.com 443" — ทดสอบบนเซิร์ฟเวอร์เองจะสำเร็จแม้โลกภายนอกจะถูกบล็อกหมด
- เช็กพอร์ตที่บริการใช้จริงหลังแก้ไฟล์ตั้งค่า พิมพ์ผิดในบรรทัด listen เป็นสาเหตุที่เจอบ่อยมากทันทีหลังแก้ไข
- ถ้าบริการไม่ยอมเริ่ม ให้อ่าน error log ก่อนลองใหม่ พอร์ตชนกัน ("address already in use") และไฟล์ตั้งค่าผิดไวยากรณ์ คือสองเหตุผลที่พบมากที่สุด
กับดัก bind-address
หัวข้อนี้ควรแยกออกมาเพราะมันสร้างเวอร์ชันที่งงที่สุดของ error ตัวนี้ คือบริการรันอยู่ชัดเจน ไฟร์วอลล์เปิดชัดเจน แต่การเชื่อมต่อยังถูกปฏิเสธ
บริการหลายตัวตั้งค่าเริ่มต้นให้ bind ที่ 127.0.0.1 ซึ่งเป็น loopback address แปลว่ามันรับแต่การเชื่อมต่อที่มาจากในเครื่องเอง อันนี้เป็นค่าเริ่มต้นด้านความปลอดภัยที่สมเหตุสมผลสำหรับฐานข้อมูลและ dev server และเป็นสิ่งที่เราต้องการจริง ๆ สำหรับ MySQL ในกรณีทั่วไป
แต่ไม่ใช่สิ่งที่เราต้องการสำหรับเว็บเซิร์ฟเวอร์สาธารณะ ถ้า ss แสดง "127.0.0.1:80" แทน "0.0.0.0:80" จุดที่ต้องแก้อยู่ในไฟล์ตั้งค่าของบริการ ไม่ใช่ไฟร์วอลล์ ใน Nginx คือ listen ใน Apache คือบรรทัด Listen ในแอป Node หรือ Python คือค่า host ที่ส่งตอนสั่งรัน — การ bind ไป "localhost" แทน "0.0.0.0" เป็นความผิดพลาดคำเดียวที่ทำให้เกิด error ตัวนี้พอดี
เหตุที่หลายคนติดกับดักนี้คือ ทดสอบบนเซิร์ฟเวอร์แล้วได้ผลดีทุกครั้ง ให้ทดสอบจากอีกเครื่องเสมอ
ป้องกันไม่ให้เกิดอีก
- สั่ง enable บริการให้รอดจากการรีบูต: "systemctl enable nginx" บริการที่เริ่มด้วยมือแต่ไม่ได้ enable จะหายไปหลังรีสตาร์ตครั้งถัดไป
- ติดตั้งระบบเฝ้าดู uptime พร้อมแจ้งเตือน รู้จากลูกค้าคือเสียครึ่งชั่วโมงแรกที่แพงที่สุดไปแล้ว
- ทดสอบไฟล์ตั้งค่าก่อนใช้จริง "nginx -t" ตรวจไวยากรณ์และจับคำที่พิมพ์ผิดซึ่งทำให้บริการรีสตาร์ตไม่ขึ้น
- จดกฎไฟร์วอลล์ไว้ กฎที่ใส่ไว้ตอนแก้ปัญหาแล้วลืมลบ จะกลายเป็นการปฏิเสธที่หาสาเหตุไม่เจอในอีกหลายเดือนถัดมา
- เฝ้าดู RAM บริการที่ถูก OOM killer เก็บจะหยุดอย่างเรียบร้อยและทำให้เกิด error ตัวนี้พอดี — สั่ง "dmesg | grep -i oom" เวลาบริการตายแบบไม่มีเหตุผลชัดเจน
- มีทางเข้าสำรองไว้ VNC หรือโหมดกู้ระบบช่วยให้เราแก้กฎไฟร์วอลล์ที่ล็อกตัวเองออกได้ ถ้าไม่มีก็เหลือแค่รอทีมซัพพอร์ต
อยากคุมบริการและไฟร์วอลล์ของตัวเองได้เต็มที่?
Cloud VPS NVMe สิทธิ์ root เต็ม — อ่าน log จริง ตั้งไฟร์วอลล์และ bind address ได้เอง เริ่ม ฿150/เดือน
คำถามที่พบบ่อย
connection refused กับ connection timed out ต่างกันยังไง
refused คือเซิร์ฟเวอร์ปฏิเสธการเชื่อมต่อแบบตั้งใจโดยส่ง TCP RST กลับมา แปลว่าไปถึงเครื่องได้และมีคนรับสาย ส่วน timed out คือไม่มีอะไรตอบกลับเลย แพ็กเก็ตถูกทิ้งที่ใดที่หนึ่งกลางทาง ตัว refused วินิจฉัยง่ายกว่ามากเพราะตัด DNS เส้นทาง และการเข้าถึงเครื่องออกได้ทั้งหมด
ทำไมเข้าเว็บไหนก็เจอ connection refused
เกือบทุกครั้งเป็นเรื่องค่า proxy การตั้ง VPN หรือส่วนขยาย proxy ให้ชี้ไป proxy ที่ตอนนี้ไม่ได้เปิดอยู่ จะทำให้ทุกการเชื่อมต่อถูกปฏิเสธ ให้เช็กค่า proxy ของระบบและส่วนขยายเบราว์เซอร์ แล้วลบอะไรที่ไม่ได้ตั้งเองออก
บริการรันอยู่แต่ยังถูกปฏิเสธ เพราะอะไร
น่าจะ bind อยู่ที่ 127.0.0.1 ไม่ใช่ 0.0.0.0 ซึ่งแปลว่ารับแต่การเชื่อมต่อจากในเครื่องเอง ให้สั่ง "ss -tlnp" แล้วดูที่อยู่ในผลลัพธ์ อันนี้อธิบายด้วยว่าทำไมทดสอบบนเซิร์ฟเวอร์แล้วได้ แต่คนข้างนอกถูกปฏิเสธ — ให้ทดสอบจากอีกเครื่องเสมอ
ERR_CONNECTION_REFUSED กระทบ SEO ไหม
กระทบ ถ้า Googlebot เป็นฝ่ายเจอ การเชื่อมต่อที่ถูกปฏิเสธแปลว่าเก็บหน้าเว็บไม่ได้เลย และถ้าเป็นต่อเนื่องหน้าเว็บจะหลุดจาก index ดูรายงาน Crawl stats ใน Search Console ว่า Googlebot เจออะไรจริง ๆ เพราะมันอาจเข้าเซิร์ฟเวอร์เราคนละเส้นทางกับเรา
GUIDES
บทความที่เกี่ยวข้อง
อ่านต่อในหัวข้อใกล้เคียง
ERR_CONNECTION_TIMED_OUT คืออะไร? แยกให้ออกว่าปัญหาอยู่ฝั่งไหน
error ตัวนี้ต่างจาก error ของเว็บทั่วไป เพราะมันเกิดก่อนที่เบราว์เซอร์จะได้คุยกับเซิร์ฟเวอร์ด้วยซ้ำ บทความนี้สอนวิธีแยกใน 2 นาทีว่าปัญหาอยู่ที่เครื่องคุณ ที่เน็ต หรือที่ตัวเว็บเอง
อ่านต่อ
502 Bad Gateway คืออะไร? เข้าใจว่าใครคุยกับใครไม่รู้เรื่อง
502 ไม่ได้แปลว่าเว็บพัง แต่แปลว่าเซิร์ฟเวอร์สองตัวคุยกันไม่รู้เรื่อง บทความนี้อธิบายว่าใครคือ gateway ใครคือปลายทาง สาเหตุที่พบบ่อย และลำดับการไล่ตรวจที่ใช้ได้จริง
อ่านต่อ
เว็บล่ม ทำยังไงดี? เช็กลิสต์ไล่หาสาเหตุที่ใช้ได้จริง
เวลาที่เว็บล่ม สิ่งที่เสียเวลาที่สุดคือการเดาสุ่ม บทความนี้ให้ลำดับการตรวจที่ตัดความเป็นไปได้ออกทีละกลุ่ม ตั้งแต่คำถามว่าล่มจริงไหม ไปจนถึงการอ่านรหัส error ให้ถูกจุด
อ่านต่อ