Proxy Setup for Restricted Networks

In many teams, optimization fails for a boring reason: route assumptions are wrong. If scan, notification, or upgrade traffic cannot reach target endpoints consistently, every downstream decision becomes noisy.

Target outcome for this session

• One stable route policy for scan, notification, and update traffic.
• Deterministic diagnostics when failures occur (stage + reason + endpoint).
• A baseline that your team can reuse across regions, machines, and operators.

This is the operational baseline you need before any governance metric can be trusted.

Step 1: Choose one route policy per workflow

Do not mix random route choices. Define intent first:

• No proxy: use when outbound HTTPS and DNS are already open and stable.
• System proxy: use when your machine policy centrally controls outbound routes.
• Custom proxy profile: use when cloud accounts and notification channels need explicit, auditable routing.

In restrictive environments, custom profiles are usually the safest option because they are explicit and reproducible.

Step 2: Create named proxy profiles with clear ownership

Create proxy profiles by use case, not by guesswork. Example naming:

• AWS-Prod-SOCKS
• AliCloud-Direct
• Telegram-Notify-SOCKS5H

Then map each cloud account and each notification channel to a specific profile. This avoids hidden coupling and makes incident analysis faster.

Step 3: Validate the full chain in the right order

Run checks in this exact sequence:

1. Proxy connectivity test.
2. Notification channel test (Telegram/Slack/Webhook).
3. Cloud account Test Connection.
4. Single-account scan.
5. Upgrade endpoint reachability (if you plan in-app updates).

Skipping sequence control creates false signals. Passing Step 3 with this order gives you a dependable operating baseline.

Failure matrix: read stage and reason before changing config

• stage=proxy_connect + reason=network_timeout: proxy endpoint itself is unreachable or blocked.
• stage=target_connect + reason=network_timeout: proxy is reachable, but target endpoint path is blocked or too slow.
• stage=config_validate: local channel/profile config is incomplete (missing URL/token/chat id).
• reason=dispatch_failure: request failed before provider returned HTTP status. Check DNS/route policy first.

Use this mapping to avoid random toggling. Change one variable at a time and re-run the same test.

Operational logging you should capture

Keep cws.log for each failed attempt window. It records stage-level diagnostics and effective route details. During support handoff, include:

• Timestamp range (UTC).
• Proxy mode and endpoint used.
• Method tested (scan/notification/update).
• Stage, reason, and HTTP status if available.

Why this matters beyond connectivity

A predictable route is part of policy quality. If route behavior is unstable, policy outcomes are unstable too.

Cloud Waste Scanner stays local-first by design: credentials remain local, route control stays with operators, and diagnostics stay inspectable. That is why this playbook is central for production use.

What comes next

In Part 3, we will cover scan result triage and execution workflow: how to prioritize findings, assign owners, and turn exports into close-loop action.

If you started from onboarding, read First Scan in 15 Minutes first, then continue with Account, Proxy, Notification, Scan Result.