หากพอร์ตด้านหน้ายังรับการเชื่อมต่อหลังจาก SSH ออกไป ให้ตรวจสอบทั้งสามยูนิต ซ็อกเก็ตสำหรับเปิดใช้งาน ตัวช่วย systemd-socket-proxyd และตัวรับฟัง SOCKS ที่ SSH สร้างขึ้นมีอายุขัยต่างกัน:

ซ็อกเก็ตตัวช่วยSSHการตีความ
กำลังรับฟังไม่ทำงานไม่ทำงานอาจรอความต้องการตามปกติ
กำลังรับฟังทำงานอยู่ทำงานอยู่มีโพรเซสอยู่ สุขภาพของปลายทางถัดไปยังไม่ได้รับการพิสูจน์
กำลังรับฟังทำงานอยู่ไม่ทำงานส่วนหน้าสามารถรับงานได้โดยไม่มีส่วนหลัง

การเริ่มตัวช่วยและ SSH พร้อมกันไม่ได้กำหนดการเปลี่ยนผ่านของการหยุดในภายหลัง สำหรับตัวช่วยที่ไม่ควรอยู่ในสถานะทำงานโดยไม่มีอุโมงค์ systemd บันทึกความสัมพันธ์ที่แข็งแรงกว่า:

[Unit]
BindsTo=ssh-socks.service
After=ssh-socks.service

นำไปใช้กับยูนิตที่เหมาะสมในการออกแบบจริง Requires= และลำดับแก้ไขได้เพียงส่วนหนึ่งของความสัมพันธ์ ส่วนหน้าที่ทำงานอยู่แล้วอาจไม่กระตุ้นการเปิดใช้งานอีกเลยหลังจากส่วนหลังหายไป ตรวจสอบสถานะยูนิตที่ล้มเหลวและขีดจำกัดอัตราการเริ่มต้นด้วย การพึ่งพาไม่ได้แทนที่ขีดจำกัดเหล่านั้น

จากนั้นสร้างความพร้อมในการเริ่มต้น After= จัดลำดับงาน ไม่ใช่ความพร้อมของตัวรับฟัง SSH Type=simple การหน่วงเวลาคงที่อาจล้มเหลวระหว่างการยืนยันตัวตนที่ช้า ใช้สัญญาการเริ่มต้นที่สร้างตัวรับฟังที่ต้องการ ExitOnForwardFailure=yes จับ ความล้มเหลวในการตั้งค่าการส่งต่อ ไม่ใช่การเข้าถึงปลายทางในภายหลัง

สุดท้าย กำหนดการออกเมื่อไม่มีการใช้งานและการเปิดใช้งานใหม่ ตัวเลือกการออกเมื่อไม่มีการใช้งานของเดมอนส่งต่อเกี่ยวข้องกับการไม่มีการเชื่อมต่อที่ทำงานอยู่ ไม่ใช่การขาดไบต์บนการเชื่อมต่อที่เปิดอยู่ เซสชันที่เงียบอาจทำให้มันยังทำงานอยู่ ความต้องการครั้งถัดไปควรเปิดใช้งานบริการที่จำเป็น และลูปการรีสตาร์ตควรมีขอบเขตและมองเห็นได้ การสร้างตัวรับฟังใหม่ยอมรับการเชื่อมต่อใหม่ มันไม่ได้กู้คืนเซสชัน TCP ที่ผ่านพร็อกซีเดิม

บทความที่เกี่ยวข้อง