તપાસો કે તમારી પ્રોક્સી બધા માટે ખુલ્લી નથી

નવી ફોરવર્ડ પ્રોક્સી બીજા નેટવર્કથી પહોંચી શકાય તેવી બનાવતા પહેલાં પ્રવેશ સીમા તપાસો. સર્વર પોતેથી સફળ વિનંતી બહારના ક્લાયન્ટની ક્ષમતા બહુ ઓછી સાબિત કરે છે. નિયંત્રિત ગંતવ્ય વાપરો જેથી નકારેલી વિનંતી ખરેખર આગળ મોકલાઈ કે નહીં જાણી શકો.

અસરકારક લિસનર અને નીતિ તપાસો

સાંભળતી પ્રક્રિયા અને સરનામાં જુઓ, IPv6 ચાલુ હોય તો તેને પણ. અનિચ્છિત વધારાના લિસનર અથવા જૂની સેવા નકલ દૂર કરો. નેટવર્ક ફાયરવોલ તે સ્ત્રોત સુધી મર્યાદિત રાખો જેને સેવા પહોંચવી જોઈએ.

પછી ખરેખર લોડ કરેલી સેટિંગ અને સામેલ ફાઇલ તપાસો. Squid 6 માં પહેલાની પરવાનગી પાછળની મર્યાદા નિષ્પ્રભ કરી શકે. Tinyproxy 1.11.2 માં બધી Allow અને Deny લાઇન દૂર કરવાથી બધા ક્લાયન્ટ મંજૂર થાય. Dante માં અલગ ક્લાયન્ટ અને SOCKS નિયમ છે, એટલે TCP જોડાણ સ્વીકારવું આખી નીતિ નથી.

ઇન્સ્ટોલ વર્ઝનના દસ્તાવેજ વાપરો. Squid 8 ના નિર્દેશ ફેરફાર વર્ઝન તપાસવાનું કારણ છે, ઓળખીતી સેટિંગ એ જ અર્થમાં સ્વીકારાઈ તેમ માનવાનું નહીં.

મંજૂર અને નકારેલા બંને કિસ્સા તપાસો

પ્રોક્સીએ મંજૂર સ્ત્રોત અને લોગઇન બંને માગવાના હોય તો પોતાના નિયંત્રિત સિસ્ટમમાં આ કોષ્ટક તપાસો:

એક NAT પાછળનાં બે ઉપકરણ એક સ્ત્રોત દેખાઈ શકે. પ્રોક્સીમાં જુદા સ્ત્રોત સરનામાં ધરાવતાં ટેસ્ટ સ્થળ પસંદ કરો અને લોગમાં ખાતરી કરો. અસંબંધિત તૃતીય પક્ષના મશીન ન લો અને બીજાની સેવા સ્કેન ન કરો.

ફાયરવોલ નકાર કોઈ HTTP જવાબ ન આપે શકે; એપનો નકાર ભૂલ આપી શકે. બંનેમાં ખાતરી કરો કે નિયંત્રિત લક્ષ્યને પ્રતિબંધિત વિનંતી મળી નથી; ફક્ત ભૂલ પેજ ગંતવ્યના જવાબ સાથે ગૂંચવાઈ શકે.

જે આગળ મોકલવાની રીત મંજૂર કરશો તે તપાસો

વેબ પ્રોક્સીમાં સામાન્ય HTTP અને મંજૂર HTTPS CONNECT માર્ગ અલગ તપાસો. નીતિ ગંતવ્ય મર્યાદિત કરે તો મંજૂર ગંતવ્ય અને નકારાવું જોઈએ તેવું નિયંત્રિત ગંતવ્ય લો. બધા ટેસ્ટ સફળ કરવા નિયંત્રણ ન કાઢો.

સ્ત્રોત રેન્જ, પ્રવેશ માહિતી, સાંભળવાના સરનામાં, સામેલ ફાઇલ કે સેવા વર્ઝન બદલાય તો ફરી તપાસો. ટેસ્ટ સમય, સેટિંગ વર્ઝન અને પરિણામ સાથે રાખો જેથી આગળનો ફેરફાર એ જ સીમાથી તપાસી શકાય.

આ સ્વીકાર પ્રક્રિયા છે, એવો દાવો નહીં કે સેટિંગ પાર્સર અથવા એક વિનંતી બધા નેટવર્ક માર્ગ બંધ છે તે સાબિત કરી શકે.