skip to content

In Postman's runtime, what does a proxy entry's tunnel flag actually change for an https target?

level: seniorimportance: nice to knowfreq 21%

answer

  1. A boolean on the proxy entry
  2. The label promises more than it decides
  3. Https targets get it regardless
  4. Not the lever for a failing call
  5. Look at disabled, bypass, match, order

basics

~20 s

Nothing observable: the runtime's requester tunnels an https target through the proxy whether or not tunnel is set on the entry. Treat the flag as an unreliable explanation and look at disabled, bypass, match and list order instead.

solid answer

~40 s

A proxy entry in the Postman SDK is a `ProxyConfig`, and it carries a boolean `tunnel`. Read as a label it looks like the switch that decides whether traffic is tunnelled — but in the runtime's requester an **https target is tunnelled through the proxy even when `tunnel` is not set**. So the flag is neither the lever that fixes a misbehaving https call nor evidence about how one travelled. When an https request takes an unexpected path, the properties that genuinely decide are elsewhere: whether the entry is `disabled`, whether a `bypass` pattern covers the URL (checked before `match`), whether `match` covers it, whether an earlier entry won, and whether the `systemProxy` fallback supplied a proxy instead. What a tunnel *means* on the wire is an HTTP-protocol subject, not a configuration one.

go deeper

for a junior

Be ready to say the entry carries a tunnel boolean alongside its host, port and pattern properties, and that it is not the setting that fixes a failing call.

for a middle

Explain the measured behaviour: the runtime's requester tunnels an https target through the proxy even with the flag unset, so it does not gate what its name suggests.

for a senior

Show the diagnostic ordering you would use instead, and state the boundary plainly: protocol-level tunnel semantics are an HTTP subject, not a claim about this client.

for a principal

Own the cost of no-op configuration: flags that do not change behaviour get credited with fixes during incidents and settle into runbooks, so name them and retire the ritual.

## The field A proxy entry in the Postman SDK (`postman-collection`) is a **`ProxyConfig`**, and among its properties is a boolean **`tunnel`**. Read as a settings label it appears to be the switch that decides whether traffic is tunnelled through the proxy rather than forwarded by it — and that reading is what makes it a good interview question, because it is not what a run actually depends on. ## What was measured In the runtime's requester code, an **https target is tunnelled through the proxy whether or not `tunnel` is set on the entry**. The behaviour a candidate expects to be gated by the flag is what an https target gets anyway. So the honest description of the flag is: - For an **https target**, setting `tunnel: true` does not change the observed path — that target is tunnelled regardless. - The flag is therefore **not** the lever to reach for when an https call through the proxy is misbehaving. - Leaving it unset is **not** evidence that an https call was forwarded rather than tunnelled. | Assumption about `tunnel` | Reality for an https target | |---|---| | it decides whether tunnelling happens | tunnelling happens without it | | unset means "definitely not tunnelled" | unset says nothing about the observed path | | it is a security or verification control | it selects a transport arrangement, nothing more | | flipping it will fix a failing https call | the cause is elsewhere in the entry or the list | ## Why this matters more than it looks Configuration flags that do not change behaviour are expensive in a different way from flags that do. They absorb debugging time, they get flipped during an incident and credited with a fix they did not cause, and they end up in a team's written runbook as a step that must be performed. A candidate who knows that `tunnel` is not the lever will look at the properties that genuinely decide the outcome instead: 1. Is the entry `disabled`, and therefore skipped before it is ever tested? 2. Does a pattern in the entry's `bypass` list cover the URL? That check runs **before** `match`, and a hit ends the entry's evaluation. 3. Does the entry's `match` pattern actually cover the URL's scheme, host and path? 4. Is an earlier entry in the list winning, since selection returns the **first** entry that applies? 5. Did nothing apply, leaving the runtime's `systemProxy` fallback to supply a proxy? Those five questions explain essentially every "my call took the wrong path" report. `tunnel` explains none of them for an https target. ## The boundary worth stating out loud There is a second, larger reason to be careful here. **What a tunnel is on the wire — how one is established, what the intermediary can and cannot observe once it exists, how connections are reused inside it — is an HTTP-protocol subject, not a Postman-configuration one.** In an interview, saying so is a strength rather than a dodge: it separates "what does this client's config field do" from "what does the protocol do", and the two questions have different right answers and different sources of truth. Keeping that line is also what stops the answer from drifting into claims about verification or trust. This entry chooses a network path. It is not the place where certificate handling or per-request transport switches are decided; those are separate surfaces with their own properties and their own resolution rules. ## How to answer it well State the measurement first, then the consequence, then the boundary: - **Measurement.** The requester tunnels an https target through the proxy even when `tunnel` is not set. - **Consequence.** The flag is not a reliable explanation for, or fix to, an https call's behaviour; look at `disabled`, `bypass`, `match`, list order and the `systemProxy` fallback instead. - **Boundary.** Protocol-level tunnel semantics belong to HTTP, not to this configuration object. That shape — what the code does, what follows for a run, and where the question stops being about this tool — is what distinguishes a candidate who has read the behaviour from one who has read the label.

  • If tunnel is not the explanation, what would you actually inspect for a misrouted https call?
    In order: whether the entry is `disabled` and therefore skipped untested; whether a `bypass` pattern covers the URL, since that check precedes `match`; whether `match` covers the URL's scheme, host and path; whether an earlier list entry won, because the first applicable entry ends the walk; and finally whether the `systemProxy` fallback supplied a proxy.
  • Why refuse to explain what tunnelling does on the wire in this answer?
    Because it is a different subject with a different source of truth. How a tunnel is established and what an intermediary can observe inside it are HTTP-protocol questions; this entry only selects a network path. Keeping the line makes the answer defensible, and it stops configuration claims from drifting into protocol claims.

saying these in an interview costs you the question

  • Says https is only tunnelled when the flag is set
  • Treats tunnel as a security or verification control
  • Flips the flag first when an https call misbehaves
  • Reads an unset flag as proof of forwarding
  • Explains protocol tunnel semantics as a Postman behaviour