Description

The intent of this article is to provide a guideline that can be used for troubleshooting general proxy availability and intermittent connectivity or backend application slowness-affiliated matters.

Environment

• Path.net

  • Proxy

  • Routed

Procedure

Please collect and gather the following data so that we may quickly identify the issue or be able to provide better assistance. Then submit a support request to Path.net support engineers. 

Data Collection

Check if any changes to your DNS or application, or routing changes recently took place include that information. Check with the application owner. This is key for effective troubleshooting.

• List out the steps to reproduce the issue that you are experiencing/reporting

• Fill in the following template with information. The more information provided, the better.

  • How is the impact observed? Support ID in case of HTTP/s blocks, timeouts, resets, etc.

  • HTTP/s FQDN and request URI

  • Public source address of the impacted client/tester(s).

  • Scope of impact (all users, some users, users of a specific carrier or region, etc.)

  • Steps to reproduce the impact

  • The output of the failure condition from a browser, curl, etc. 

  • If the issue can be reproduced using the browser, collect a HAR file.

    • For instructions refer to: How to Generate HAR Files

  • Packet capture on a client, if available

  • Testing account/credentials (if available and necessary)

  • Start time of observed impact, end time if applicable, or ongoing

• Check and verify the following features using this as a guideline (there may be other features that are not listed below)

  • Check if the backend responds by connecting to the backend directly, bypassing Silverline proxy

    • Adding an entry to the host file can help to bypass Path.net web application proxy by using static DNS host entries. 

  • For Proxies with HTTP/s Filter(s), check by viewing global rate-limiters or portal user visualizations.

Tools and Commands

Resolve the domain name to IP address

• For Windows, 

  • nslookup <host_name>

  • # nslookup www.example.com

• For *nix users can use dig

  • dig <host_name> -short

  • # dig www.example.com -short

• On *nix systems one can use tools such as Wget or cURL to check the connectivity with the destination host using bash. For the use and syntax please refer to online documentation

  • WGET

    • time wget https://<domain>/

    • time wget https:/192.168.1.1/

• cURL

  • #For a quick test measured in time: 

    curl -k -w "Testing Website Response Time for: %{url_effective}\n\nLookup Time:\t\t%{time_namelookup}\nConnect Time:\t\t%{time_connect}\nAppCon Time:\t\t%{time_appconnect}\nRedirect Time:\t\t%{time_redirect}\nPre-transfer Time:\t%{time_pretransfer}\nStart-transfer Time:\t%{time_starttransfer}\n\nTotal Time:\t\t%{time_total}\n" -Lvi https://<domain-name>/  --resolve <domain-name>:<port>:<ip>

     

    Lookup Time: 0.000065

    Connect Time: 0.000067

    AppCon Time: 0.000067

    Redirect Time: 1.219776

    Pre-transfer Time: 0.000165

        Start-transfer Time: 0.216281

    Total Time: 1.438582

  • Modify "https://<domain-name>/  --resolve <fqdn>:<port>:<ip>

  • The "--resolve <fqdn>:<port>:<ip>" is useful for SNI enabled applications/servers

  • curl -vkLi https://www.example.com/  --resolve www.example.com:443:'{public virtual adress}'

• For SSL related issue 'openssl s_client -connect ' can be used

  • openssl s_client -connect <IP>:<Port> -servername <domain-name>

  • The "-servername <domain>" is useful for SNI enabled applications/servers

  • openssl s_client -connect 192.168.1.1:443 -servername www.example.com

• Once data has been collected, engage and reach out to Path.net Engineering team by opening a support request with our team.