در گزارش خطای پراکسی چه بنویسیم

مرحلهٔ شکست و خطای دقیق را به پشتیبانی بدهید، نه فقط «پراکسی کار نمی‌کند». گزارش کوتاه می‌تواند این ساختار را داشته باشد:

Client and version:
Proxy protocol and port:
Attempt time and timezone:
Connection / overall timeout settings:
Last completed stage:
Exact error or numeric status:
Same target over an allowed direct route:
Same target through another comparable endpoint:

مرحله را اتصال پراکسی، احراز هویت پراکسی، ساخت تونل، TLS مقصد یا پاسخ نهایی HTTP توصیف کنید. مثلاً «پراکسی HTTP روی درگاه 8080؛ TCP متصل؛ CONNECT پاسخ 407 داده؛ هنوز TLS مقصد شروع نشده» بدون افشای اطلاعات ورود مشکل را مشخص می‌کند. برای خطای گواهی، دستهٔ خطا و زمینهٔ نام میزبان مورد انتظار را حفظ و در صورت نیاز نام‌های خصوصی را پنهان کنید.

پیش از اشتراک‌گذاری، متن واقعی را بازبینی کنید. userinfo در URL پراکسی، Proxy-Authorization، Authorization مقصد، Cookie، Set-Cookie، مقادیر خصوصی پرس‌وجو و بدنهٔ درخواست‌ها را حذف کنید. کوکی نشست یا bearer token می‌تواند بدون شباهت به گذرواژه دسترسی بدهد. پوشاندن ابزارها با نسخه و حالت خروجی فرق می‌کند؛ گزارش تفصیلی و ردگیری کامل لزوماً یکسان پنهان نمی‌کنند.

از نشانه‌هایی مانند REDACTED_PROXY_PASSWORD استفاده کنید و نام سرآیندها، ساختار URL و خطاهای عددی را قابل مشاهده نگه دارید. کل تبادل اطراف شکست را حذف نکنید. نقاط پایانی خصوصی و جزئیات شبکه را فقط در کانال مناسب پشتیبانی به اشتراک بگذارید.

اگر درخواست حداقلی به مقصدی بی‌خطر یا سرویسی تحت کنترل شما مشکل را بازتولید می‌کند، به‌جای ردگیری داده‌های کاری آن را ارائه کنید. اگر خطا فقط با مقصد اصلی رخ می‌دهد، بگویید: عوض کردن مقصد، چیزی را که بازتولید اثبات می‌کند تغییر می‌دهد. برای پراکسی HTTP، درخواست curl با زمان محدود می‌تواند نمونهٔ حداقلی باشد.