अगर SSH के बाहर निकलने के बाद भी फ़्रंट पोर्ट कनेक्शन स्वीकार करता है, तो तीनों यूनिट जाँचें। एक्टिवेशन सॉकेट, systemd-socket-proxyd सहायक और SSH द्वारा बनाया गया SOCKS श्रोता अलग-अलग जीवनकाल रखते हैं:

सॉकेटसहायकSSHव्याख्या
सुन रहा हैनिष्क्रियनिष्क्रियसामान्य रूप से माँग की प्रतीक्षा कर रहा हो सकता है
सुन रहा हैसक्रियसक्रियप्रक्रियाएँ हैं; परंतु आगे के गंतव्य का स्वास्थ्य अभी सिद्ध नहीं
सुन रहा हैसक्रियनिष्क्रियफ़्रंट एंड अपने बैकएंड के बिना काम ले सकता है

सहायक और SSH को साथ शुरू करना बाद के स्टॉप बदलाव को परिभाषित नहीं करता। जिस सहायक को अपनी टनल के बिना सक्रिय नहीं रहना चाहिए, उसके लिए systemd अधिक मज़बूत संबंध दर्ज करता है:

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

वास्तविक डिज़ाइन में उपयुक्त यूनिट पर इसे लागू करें। Requires= और क्रम संबंध का केवल एक भाग संभालते हैं। पहले से सक्रिय फ़्रंट एंड अपने बैकएंड के लुप्त होने के बाद शायद फिर कभी एक्टिवेशन न छेड़े। विफल यूनिट की स्थिति और स्टार्ट-रेट सीमाएँ भी जाँचें; निर्भरताएँ उन सीमाओं को नहीं हटातीं।

इसके बाद स्टार्टअप तैयारी स्थापित करें। After= कार्यों का क्रम तय करता है, Type=simple SSH श्रोता की तैयारी नहीं। धीमे प्रमाणीकरण के दौरान निश्चित प्रतीक्षा विफल हो सकती है। आवश्यक श्रोता स्थापित करने वाला स्टार्टअप अनुबंध इस्तेमाल करें; ExitOnForwardFailure=yes फ़ॉरवर्डिंग सेटअप की विफलता पकड़ता है, बाद की गंतव्य-पहुँच नहीं।

अंत में निष्क्रिय निकास और पुनःसक्रियण परिभाषित करें। फ़ॉरवर्डिंग डेमॉन का निष्क्रिय-निकास विकल्प सक्रिय कनेक्शनों की अनुपस्थिति से संबंधित है, खुले कनेक्शन पर बाइटों की कमी से नहीं। शांत सत्र उसे सक्रिय रख सकता है। अगली माँग को आवश्यक सेवाएँ सक्रिय करनी चाहिए, और रीस्टार्ट लूप सीमित तथा दृश्य रहने चाहिए। श्रोता को फिर से बनाना नए कनेक्शन स्वीकार करता है; यह पुराने प्रॉक्सी किए गए TCP सत्र बहाल नहीं करता।

संबंधित लेख