caddyserver / forwardproxy Goto Github PK

1. Is bug reproducible with latest forwardproxy build?

yes

2. What are you trying to do?

help fix this bug,or show me how,thx.

3. What is your entire Caddyfile?

https://your_domain.xxx {
    basicauth / yourname yourpassword
    browse
    forwardproxy {
        basicauth absudra absudra!!!
        ports 443
        hide_ip
        hide_via
        acl {
        allow     *.caddyserver.com
        deny      192.168.1.1/32 192.168.0.0/16 *.prohibitedsite.com *.localhost
        allow     ::1/128 8.8.8.8 github.com *.github.io
#        allowfile /path/to/whitelist.txt
#        denyfile  /path/to/blacklist.txt
        allow     all
        deny      all # unreachable rule, remaining requests are matched by `allow all` above
        }
    }
}

4. How is your client configured?

via proxyomega as https proxy with successful connection.

5. How did you run Caddy? (give the full command and describe the execution environment). If multiple servers are used (for example with upstream), describe those as well.

/usr/local/bin/caddy -log stdout -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp

6. Please paste any relevant HTTP request(s) here.

Usually,it works well.Sometimes ,such as visit blogspot,git.kali.org,etc.then it always return 403.googled that ,someone say ,which is caused by the website i visited had deplyed with $$,I dont know what means.

7. What did you expect to see?

wish to fix it.If it has difficult,then figure me how to avoid it.

8. What did you see instead (give full error messages and/or log)?

the chrome browser dev tools show nothing.
on the caddyserver side,i also couldnt find any clue.

9. How can someone who is starting from scratch reproduce the bug as minimally as possible?

I dont know.If you know,welcome your reply.

Here's my caddyfile (I have to use port 443 for other reasons, but this happens on any port):

pi:443 {
    tls off
}
proxy.website.com:443 {
    forwardproxy {
        basicauth username password
        serve_pac config.pac
    }
    tls off
}

pi is my server's hostname in my LAN. A proxy is hosted at proxy.website.com, which is what should be happening. The problem is, it's also hosted on port 443 on any other domain. This Caddyfile is just one example. No matter what I try, I can't only host the proxy on one domain, no matter the port or domain.

Another example:

website.com:80 {
    root websiteroot
    ext html htm
}
proxy.website.com:80 {
    forwardproxy {
        basicauth username password
    }
}

Here, a webpage won't get served at website.com:80.
Instead, a proxy will. this makes it impossible to have a proxy served only on a subdomain, on the same port.

1. Is bug reproducible with latest forwardproxy build?

Yes

2. What are you trying to do?

Config a forward proxy.

3. What is your entire Caddyfile?

example.com:8443
log access.log
tls /root/cert/cert.cer /root/cert/privatekey.pem
forwardproxy {
        basicauth user1 12345678
        ports 10443
        hide_ip
        hide_via
        probe_resistance secret.localhost
        response_timeout 30
        dial_timeout 30
}

4. How is your client configured?

SwitchyOmega plug-in with Chromium browser.

5. How did you run Caddy? (give the full command and describe the execution environment). If multiple servers are used (for example with upstream), describe those as well.

caddy -conf CaddyFile

6. Please paste any relevant HTTP request(s) here.

7. What did you expect to see?

Browse Internet through a HTTPS proxy. (example.com:10443)

8. What did you see instead (give full error messages and/or log)?

Chromium reports “ERR_PROXY_CONNECTION_FAILED” and the access.log is empty.

9. How can someone who is starting from scratch reproduce the bug as minimally as possible?

go get -d -u -t github.com/caddyserver/forwardproxy/... github.com/mholt/caddy/...
package github.com/caddyserver/forwardproxy
imports github.com/lucas-clemente/quic-go/h2quic: cannot find package "github.com/lucas-clemente/quic-go/h2quic" in any of:
/usr/local/go/src/github.com/lucas-clemente/quic-go/h2quic (from $GOROOT)
/home/gopath/src/github.com/lucas-clemente/quic-go/h2quic (from $GOPATH)

1. What version of Caddy are you using (caddy -version)?

Caddy 0.11.0 (non-commercial use only)

2. What are you trying to do?

to forward a https proxy

3. What is your entire Caddyfile?

(paste Caddyfile here)

example.com ## My site
gzip
log /var/log/caddy/access.log
root /usr/share/www

forwardproxy {
basicauth user passwd
hide_ip
probe_resistance secretlink.localhost
}

4. How did you run Caddy (give the full command and describe the execution environment)?

caddy -c /etc/caddy.conf

5. Please paste any relevant HTTP request(s) here.

6. What did you expect to see?

chrome + swithyomega can surf the web through the proxy WITH AN AUTHORIZATION

7. What did you see instead (give full error messages and/or log)?

It works well when there is no Authorization. However, when i add the "basicauth user passwd" in the caddy file, and fill the same user/passwd in the switchyomega configuration, it does not work.

This is the log from caddy:
28/May/2018:06:55:03 +0100 [ERROR 0 ] Proxy-Authorization is required! Expected format:

8. How can someone who is starting from scratch reproduce the bug as minimally as possible?

1, set "basicauth user passwd" in caddy configuration;
2, fill the same user/password in switchyomega configuration;
3, browser some sites with the proxy, and it just cannot work.

Plz support Caddy2
Why I need Caddy2 forwardproxy: https://medium.com/@mattholt/private-browsing-without-a-vpn-e91027552700

===updated at 30/7/2020===
I found a fork
https://github.com/klzgrad/forwardproxy

我有一台韩国VPS,并成功搭建了代理，韩国也有墙，不能访问某些小姐姐网站。怎么把只访问小姐姐的流量转发到香港VPS上处理呢？

What are you trying to do?
I am trying to develop the forwardproxy plugin to add some custom functions.
But I can't plug your plugin.

I have add import '_ "github.com/caddyserver/forwardproxy"' into run.go, but got error "___go_build_main_go flag redefined: https-port"

It suggest that have some conflict with "github.com/mholt/caddy/caddyhttp", both of plugin use the args "https-port".
+++++++++++++++++++++++++++++++++++++++++++++++
/private/var/folders/2z/t_s4dwc130l7z3xq0mbdmppc0000gn/T/___go_build_main_go flag redefined: https-port
panic: /private/var/folders/2z/t_s4dwc130l7z3xq0mbdmppc0000gn/T/___go_build_main_go flag redefined: https-port

goroutine 1 [running]:
flag.(*FlagSet).Var(0xc000094180, 0x1eaa680, 0x261d880, 0x1d7c6e2, 0xa, 0x1d89afc, 0x1d)
/usr/local/go/src/flag/flag.go:805 +0x6e3
flag.StringVar(0x261d880, 0x1d7c6e2, 0xa, 0x1d76888, 0x3, 0x1d89afc, 0x1d)
/usr/local/go/src/flag/flag.go:714 +0x99
github.com/caddyserver/forwardproxy/vendor/github.com/mholt/caddy/caddyhttp/httpserver.init.1()
/Users/sweetdreams/go/src/github.com/caddyserver/forwardproxy/vendor/github.com/mholt/caddy/caddyhttp/httpserver/plugin.go:39 +0x73

1. Is bug reproducible with latest forwardproxy build?

2. What are you trying to do?

i use caddy as a http proxy for a existed local socks5 proxy. in 127.0.0.1:1086, there is a sock5 server.

3. What is your entire Caddyfile?

127.0.0.1:60886 {
	forwardproxy {
		upstream	socks5://127.0.0.1:1086
	}
}

4. How is your client configured?

curl -x http://127.0.0.1:60886 some-url

5. How did you run Caddy? (give the full command and describe the execution environment). If multiple servers are used (for example with upstream), describe those as well.

6. Please paste any relevant HTTP request(s) here.

7. What did you expect to see?

200 response

8. What did you see instead (give full error messages and/or log)?

502 Bad Gateway

9. How can someone who is starting from scratch reproduce the bug as minimally as possible?

1. What version of Caddy are you using (caddy -version)?

0.11.0

2. What are you trying to do?

use caddy as a forward proxy chain

3. What is your entire Caddyfile?

    forwardproxy {
        response_timeout 30
        dial_timeout     30
        ports     80 443
        upstream  https://user:[email protected]:443
    }
    root /root/bin/caddy/html
    gzip
    errors /root/bin/caddy/1936/error.log
    log /root/bin/caddy/1936/access.log
}

4. How did you run Caddy (give the full command and describe the execution environment)?

ulimit -n 16384 && caddy
on debian 9
load balanced by haproxy ( with statics ), than export to internal user.

5. Please paste any relevant HTTP request(s) here.

6. What did you expect to see?

a few ESTABLISHED connection to remote host after running a few hours

7. What did you see instead (give full error messages and/or log)?

a lot of connection
netstat -an | grep 64.xxx.xx.xxx | grep ESTABLISHED| wc -l
123
on haproxy statics page, current session is only 17 and max session is 67.

8. How can someone who is starting from scratch reproduce the bug as minimally as possible?

sorry, no clue yet, I've try do curl every 15 secs, but can not reproduce.

So I hope someone can explain upstream connection reuse and timeout rule for me.

1. What version of Caddy are you using (caddy -version)?

Caddy 0.10.12 (non-commercial use only)
Chrome + SwitchyOmega

2. What are you trying to do?

forwardproxy not work

3. What is your entire Caddyfile?

caddy.dsh.li
root /data/web/org/
errors errors.log
log access.log


forwardproxy {
    basicauth user pass
    ports     80 443
    hide_ip
    probe_resistance secret.localhost
    response_timeout 30
    dial_timeout     30
}

4. How did you run Caddy (give the full command and describe the execution environment)?

caddy

5. Please paste any relevant HTTP request(s) here.

==> access.log <==
115.231.93.68 - - [10/Apr/2018:07:24:03 +0000] "CONNECT / HTTP/2.0" 421 61

==> errors.log <==
10/Apr/2018:07:24:05 +0000 [ERROR 0 ] Proxy-Authorization is required! Expected format: <type> <credentials>

6. What did you expect to see?

config my proxy server by
https://medium.com/@mattholt/private-browsing-without-a-vpn-e91027552700

7. What did you see instead (give full error messages and/or log)?

8. How can someone who is starting from scratch reproduce the bug as minimally as possible?

1. Is bug reproducible with latest forwardproxy build?

Yes

2. What are you trying to do?

Trying to connect the proxy

3. What is your entire Caddyfile?

a.example.com, b.example.com {
    forwardproxy {
        basicauth user1 123456
        ports 80 443 11001
        response_timeout 30
        dial_timeout     30
    }
    root /root/www
}

4. How is your client configured?

5. How did you run Caddy? (give the full command and describe the execution environment). If multiple servers are used (for example with upstream), describe those as well.

Under CentOS 7
caddy -conf Caddyfile

6. Please paste any relevant HTTP request(s) here.

7. What did you expect to see?

The proxy working on all three ports.

8. What did you see instead (give full error messages and/or log)?

When I try on port 80, it gave me "404 Site google.com is not served on this interface" on Firefox and "ERR_TUNNEL_CONNECTION_FAILED" on Chrome
On port 443, it gave me "Connection Reset" on Firefox and "ERR_EMPTY_RESPONSE" on Chrome
On port 11001, it gave me "Connection Reset" on Firefox and "ERR_PROXY_CONNECTION_FAILED" on Chrome

9. How can someone who is starting from scratch reproduce the bug as minimally as possible?

The post https://sfrolov.io/2017/08/secure-web-proxy-client-en did not exist any more.

The javascript below is generated by SwitchyOmega. It does some sorcery and then specifies that connections to localhost shouldn't go via proxy.

Would be nice to figure out what exactly is going on and, at least, allow users to access localhost directly.

SwitchyOmega auto-generated PAC file:

var FindProxyForURL = function(init, profiles) {
    return function(url, host) {
        "use strict";
        var result = init, scheme = url.substr(0, url.indexOf(":"));
        do {
            result = profiles[result];
            if (typeof result === "function") result = result(url, host, scheme);
        } while (typeof result !== "string" || result.charCodeAt(0) === 43);
        return result;
    };
}("+proxy", {
    "+proxy": function(url, host, scheme) {
        "use strict";
        if (/^127\.0\.0\.1$/.test(host) || /^::1$/.test(host) || /^localhost$/.test(host)) return "DIRECT";
        return "HTTPS sfrolov.io:443";
    }
});

[For Reference] Current auto-generated PAC file:

function FindProxyForURL(url, host) {
	return "HTTPS %s:%s";
}

Hi

is it possible to proxy also video streams with different video mime types like:

iPhone Index | .m3u8 | application/x-mpegURL
iPhone Segment | .ts | video/MP2T
3GP Mobile | .3gp | video/3gpp
QuickTime | .mov | video/quicktime
A/V Interleave | .avi | video/x-msvideo
Windows Media | .wmv | video/x-ms-wmv

Tkanks and regrads

Good afternoon.
I need to run this configuration, but it does not work. I think that there is a mistake.
Could you explain what I'm doing wrong?

https://1.example.com
tls self_signed
proxy / localhost:3000 {
websocket
transparent
}
https://2.example.com
tls self_signed
proxy / localhost:3001 {
websocket
transparent
}

Any plan to upstream proxy support?
Sometimes we want access another proxy to connect some host, but it's not secure and it might be blocked, use a secure & hidden proxy to connect is useful.

@mholt
Is it planned / possible to add acls / filters to restrict access to destinations by domain / path / ip? Or maybe blacklists / whitelists in files?

Can we have a radius option for basicauth?

https://github.com/jamesboswell/caddy-radius

Thanks.

It seems like we really can use this without an app on Android, but only if the proxy includes a PAC file. That should be trivial to do.

For non-probing-resistant proxies, the PAC file should probably live at /proxy.pac. For hidden-link proxies, something like /[hidden domain].pac would work.

Eventually it would be cool to support smarter custom PAC files, but that can happen later.

1. What version of Caddy are you using (caddy -version)?

2. What are you trying to do?

3. What is your entire Caddyfile?

(paste Caddyfile here)

4. How did you run Caddy (give the full command and describe the execution environment)?

5. Please paste any relevant HTTP request(s) here.

6. What did you expect to see?

7. What did you see instead (give full error messages and/or log)?

8. How can someone who is starting from scratch reproduce the bug as minimally as possible?

Will caddy / forwardproxy cache dns requests?

I changed /etc/hosts during calls. Lookup is fine local, but caddy forwardproxy use the old ip address instead of the new one.

Disable caddy / forwardproxy dns cache would be great for my use case.
Is it plugin or caddy related?

e.g:
We have a forwardproxy for https://proxy.plus on host A, and a web site https://web.plus ( different from proxy.plus ) on the same host with caddy. P.S. enable tls always.

When browse the https://web.plus via https://proxy.plus proxy, chrome says "ERR_TUNNEL_CONNECTION_FAILED".

Other web sites work okay via https://proxy.plus.

Android connected to the forwardproxy server, I have been through the yadex or firefox plugin: SwitchyOmega successfully connected.
But this method can't be used in other APPs. I have tried Drony, ProxyDroid, and can't connect to the server.
Until today, I found a very useful client that allows other apps to connect to the forwardproxy server.

Project link: https://github.com/zxc111/SmartProxy

(I know I could just fix it real quick myself in this case, but I'm trying to notify as many plugins as I can)

Caddy's import path (and Go module name) has changed from

github.com/mholt/caddy

to

github.com/caddyserver/caddy

Unfortunately, Go modules are not yet mature enough to handle a change like this (see https://golang.org/issue/26904 - "haven't implemented that part yet" but high on priority list for Go 1.14) which caught me off-guard. Using Go module's replace feature didn't act the way I expected, either. Caddy now fails to build with plugins until they update their import paths.

I've hacked a fix into the build server, so downloading Caddy with your plugin from our website should continue working without any changes on your part, for now. However, please take a moment and update your import paths, and do a new deploy on the website, because the workaround involves ignoring module checksums and performing a delicate recursive search-and-replace.

I'm terribly sorry about this. I did a number of tests and dry-runs to ensure the change would be smooth, but apparently some unknown combination of GOPATH, Go modules' lack of maturity, and other hidden variables in the system or environment must have covered up something I missed.

This bash script should make it easy (run it from your project's top-level directory):

find . -name '*.go' | while read -r f; do
	sed -i.bak 's/\/mholt\/caddy/\/caddyserver\/caddy/g' $f && rm $f.bak
done

We use this script in the build server as part of the temporary workaround.

Let me know if you have any questions! Sorry again for the inconvenience.

Caddyfile：

domain1.net
{
root /var/www/html1
tls [email protected]
forwardproxy {
basicauth user1 pass1
hide_ip
hide_via
probe_resistance
upstream http://127.0.0.1:1080
}
}
domain2.net
{
root /var/www/html2
tls [email protected]
forwardproxy {
basicauth user2 pass2
hide_ip
hide_via
probe_resistance
upstream http://127.0.0.1:1081
}
}

Configure the second Web site does not work！

2. What are you trying to do?

Someone on the forum suggested to ask here.

Can Caddy (2) work as a transparent TLS interception proxy similar to squid? The readme only mentions http.

Here is my config:

https://<my_domain_name>:993 {
  gzip

  tls <my_email> {
    alpn h2
  }

  forwardproxy {
    basicauth <username> <password>
    probe_resistance hello.localhost
    hide_ip
    hide_via
  }

  log stdout
}

In port 443, it works fine, but I set port to 993, it can be connect via no auth.

Are there any plans on adding an option to hide the proxy server itself?

For example removing the via header. I know this would violate the HTTP 1.1 spec but some people may want this as some sites don't allow connections from proxies.

1. Is bug reproducible with latest forwardproxy build?

Yes

2. What are you trying to do?

Use the proxy with authentication through Drony

3. What is your entire Caddyfile?

http://my.valid.domain, https://my.valid.domain {
  forwardproxy {
    basicauth user password
    acl {
      allow all
    }
  }
  log stdout
  errors stderr
}

4. How is your client configured?

specifying username and password like pointed out here

5. How did you run Caddy? (give the full command and describe the execution environment). If multiple servers are used (for example with upstream), describe those as well.

Using custom docker image

6. Please paste any relevant HTTP request(s) here.

7. What did you expect to see?

A successful HTTP Request

8. What did you see instead (give full error messages and/or log)?

The client only get Proxy Authentication Required but does not retry with the specified username. Meanwhile when connecting to Squid Proxy with basic authentication (which return Proxy-Authenticate: Basic realm="proxy"), it retry with the specified credential

9. How can someone who is starting from scratch reproduce the bug as minimally as possible?

Run caddy forward proxy with basicauth and use it through Drony

We should reject connections to localhost, unless it's specifically allowed, since this is potential security issue. We also should allow to override this policy.

• Reject connections to localhost
• Allow upstreaming with insecure schemes, like http and socks5, to localhost
• Implement #11 "ACLs / filter features", which would allow to override default "no CONNECT to localhost" policy by whitelisting it.

I have a special use case and would need to use a custom hosts file instead of /etc/hosts.
Would it possible to add such a config option like squid proxy have?
http://www.squid-cache.org/Doc/config/hosts_file/

Recently we implemented long-requested access control lists feature #11, and added manual dialing in order to control that attacker could not get access to forbidden destinations with sneaky redirects in http responses.
Unfortunately, for all those nasty over-9000-http-requests workloads, we now establish separate tcp connection for each request. Establishing tcp connection to get favicon and then close is no bueno performance-wise.
We can solve this by passing a custom dialer(with built-in ACL) to http.Transport and letting HTTP package do socket pooling and reuse.

1. Is bug reproducible with latest forwardproxy build?

Yes

2. What are you trying to do?

using forwardproxy toghther with caddy's built-in TLS client certificate auth. the same configuration works fine without that clients config/cert.pem line. The exact same configuration works fine when not using proxy (i.e., just website hosting)

3. What is your entire Caddyfile?

https://www.mywebsite.com

log server.log
gzip
root host    

tls /etc/letsencrypt/live/www.mywebsite.com/fullchain.pem /etc/letsencrypt/live/www.mywebsite.com/privkey.pem {
    clients config/cert.pem
}

forwardproxy

4. How is your client configured?

5. How did you run Caddy? (give the full command and describe the execution environment). If multiple servers are used (for example with upstream), describe those as well.

just run it in the bash

6. Please paste any relevant HTTP request(s) here.

7. What did you expect to see?

The proxy working. Client certificate and https proxy works fine when I use the software I wrote using nodejs with chrome, meaning chrome supports such configuration. so the problem is on the server side.

8. What did you see instead (give full error messages and/or log)?

chrome gives me ERR_PROXY_CONNECTION_FAILED.

9. How can someone who is starting from scratch reproduce the bug as minimally as possible?

1. generate a tls key-cert pair, transform these into a .p12 file
2. using the same caddy configuation, add some static files to host folder and the certificate generated at step 1 to the config folder
3. add the .p12 file to chrome (OS dependent)
4. you should be able to access the page, but there will be error when using it as proxy

NOTE: in practice I don't use chrome directly with the proxy, but that doesn't matter since the error occur anyway.

1. What version of Caddy are you using (caddy -version)?

Caddy 0.11.0

2. What are you trying to do?

Make a http2 proxy use caddy, I hope it can support WebSocket.

I use Chrome + SwitchyOmega for client.

PAC file:

function FindProxyForURL(url, host) {
  return "HTTPS example.com:443";
}

3. What is your entire Caddyfile?

example.com:443 {
    tls /***/cert.pem /***/privkey.pem
    forwardproxy {
        basicauth user pass
        hide_ip
        hide_via
        response_timeout 10
        dial_timeout 10
    }
}

4. How did you run Caddy (give the full command and describe the execution environment)?

caddy --conf Caddyfile

5. Please paste any relevant HTTP request(s) here.

Please open this js code example:

http://jsbin.com/muqamiqimu/2/edit?js,console

Click run, modify the first line from wss://echo.websocket.org to ws://echo.websocket.org, and run again.

6. What did you expect to see?

Both protocols should be supported (ws and wss).

7. What did you see instead (give full error messages and/or log)?

Only wss supported, ws cant work, which works normally without proxy.

8. How can someone who is starting from scratch reproduce the bug as minimally as possible?

• Install caddy with forwardproxy.
• Copy Caddyfile.
• Run caddy as a http2 proxy server.
• Configure Chrome to use the http2 proxy.
• Open the URL I support in above and test.

1. What version of Caddy are you using (caddy -version)?

Caddy 0.11.0

2. What are you trying to do?

Access Tor Hidden Service though Caddy (use Tor as upstream).

3. What is your entire Caddyfile?

mydomain.com {
	forwardproxy {
		hide_ip
		hide_via
		upstream socks5://localhost:9050
	}
}

4. How did you run Caddy (give the full command and describe the execution environment)?

Follow https://github.com/mholt/caddy/blob/master/dist/init/linux-systemd/caddy.service , use Ubuntu 18.04 LTS.

5. Please paste any relevant HTTP request(s) here.

:authority: 3cvpkfx4gdnkcduj.onion
:method: GET
:path: /
:scheme: http
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
accept-encoding: gzip, deflate
accept-language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7
cache-control: max-age=0
dnt: 1
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3472.3 Safari/537.36

6. What did you expect to see?

I can access the Tor Hidden Service.

7. What did you see instead (give full error messages and/or log)?

Browser: 502 Bad Gateway
Server(time is removed):

[ERROR 502 /] dial  failed: socks connect tcp: missing port in address
[ERROR 0 ] readfrom tcp 127.0.0.1:21728->127.0.0.1:9050: stream error: stream ID 15; CANCEL
[ERROR 0 ] readfrom tcp 127.0.0.1:21720->127.0.0.1:9050: stream error: stream ID 11; CANCEL
[ERROR 0 ] readfrom tcp 127.0.0.1:21724->127.0.0.1:9050: stream error: stream ID 13; CANCEL
[ERROR 502 /favicon.ico] dial  failed: socks connect tcp: missing port in address
[ERROR 0 ] readfrom tcp 127.0.0.1:21732->127.0.0.1:9050: stream error: stream ID 17; CANCEL

8. How can someone who is starting from scratch reproduce the bug as minimally as possible?

Use Tor as upstream, and access a Tor Hidden Service(Accessing clearnet sites using Tor upstream works well).

1. Is bug reproducible with latest forwardproxy build?

2. What are you trying to do?

3. What is your entire Caddyfile?

(paste Caddyfile here)

4. How is your client configured?

5. How did you run Caddy? (give the full command and describe the execution environment). If multiple servers are used (for example with upstream), describe those as well.

6. Please paste any relevant HTTP request(s) here.

7. What did you expect to see?

8. What did you see instead (give full error messages and/or log)?

9. How can someone who is starting from scratch reproduce the bug as minimally as possible?

1. Is bug reproducible with latest forwardproxy build?

Yes

2. What are you trying to do?

setup both forward proxy and reverse proxy on the same node and each other with different SNI

3. What is your entire Caddyfile?

	(wildcard_cert) {
	  tls ${LETSENCRYPT_NOTIFICATION_EMAIL} {
	    dns cloudflare
	    wildcard
	  }
	}
	${REVERSE_PROXY_SERVER} {
	  import wildcard_cert
	  log stdout
	  errors stderr
	  root /var/www/ 
	  proxy /blog localhost:8080 {
	    websocket
	    header_upstream -Origin
	  }
	}
	${FORWARD_PROXY_SERVER} {
	  import wildcard_cert
	  log stdout
	  errors stderr
	  root /var/www/ 
	  forwardproxy {
	    basicauth ${USER} ${PASSWORD}
	    ports     80 443
	    hide_ip
	    hide_via
	    probe_resistance ${SECRET_LINK}
	    serve_pac ${PAC_FILE_NAME}
	    response_timeout 30
	    dial_timeout     30
	    acl {
	      allow     ::1/128 8.8.8.8 github.com *.github.io
	      deny      192.168.1.1/32 192.168.0.0/16 *.prohibitedsite.com *.localhost
	      allow     all
	      deny      all # unreachable rule, remaining requests are matched by 'allow all' above
	    }
	  }
	}

4. How is your client configured?

The SwitchyOmega chrome extension has been setup properly and could surf web via the HTTPS proxy server if comment out the line of 'probe_resistance'

5. How did you run Caddy? (give the full command and describe the execution environment). If multiple servers are used (for example with upstream), describe those as well.

6. Please paste any relevant HTTP request(s) here.

'''
CLOUDFLARE_EMAIL=$CLOUDFLARE_EMAIL CLOUDFLARE_API_KEY=$CLOUDFLARE_API_KEY /usr/local/bin/caddy -env -log stdout -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp
'''

7. What did you expect to see?

surf the internet without issue

8. What did you see instead (give full error messages and/or log)?

== The chrome browser
denies web access with error message
"ERR_TUNNEL_CONNECTION_FAILED"

== Caddy console

22/Jun/2019:13:45:50 +0800 [ERROR 0 ] Proxy-Authorization is required! Expected format: <type> <credentials> 

9. How can someone who is starting from scratch reproduce the bug as minimally as possible?

hi.
i'm using caddy's https proxy feature.
root@umh:# cat /root/caddyfile
mydomain.com:3443 {
gzip
log access.log
forwardproxy
}
root@umh:# lsof -i:80
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
caddy 349 root 6u IPv6 183473 0t0 TCP *:http (LISTEN)
root@umh:#
root@umh:# lsof -i:3443
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
caddy 349 root 5u IPv6 183472 0t0 TCP *:3443 (LISTEN)
root@umh:~#

in my caddyfile,i didn't mention port 80,why caddy occupies/listen on port 80?
how to make caddy not listen to port 80?

1. Is bug reproducible with latest forwardproxy build?

Yes

2. What are you trying to do?

Use ipv6 to visit websites.

3. What is your entire Caddyfile?

forwardproxy {
    basicauth xxx xxxxxxx
    ports     80 443
    hide_ip
    hide_via
    probe_resistance
    response_timeout 30
    dial_timeout     30

4. How is your client configured?

Use Surge HTTPS Proxy.

5. How did you run Caddy? (give the full command and describe the execution environment). If multiple servers are used (for example with upstream), describe those as well.

In docker container.

6. Please paste any relevant HTTP request(s) here.

7. What did you expect to see?

The proxy is working but only by ipv4, my server have ipv6 address and a shadowsocks proxy in another container can use ipv6 successful. I want to confirm if ipv6 is supported in forwardproxy.

8. What did you see instead (give full error messages and/or log)?

9. How can someone who is starting from scratch reproduce the bug as minimally as possible?

1. Is bug reproducible with latest forwardproxy build?

Yes
and I've try build myself, a035ebe works, and 27401eb failed.

2. What are you trying to do?

forward with upstream caddy proxy

3. What is your entire Caddyfile?

upstream setting

xyz.xyz.info {
    forwardproxy {
        basicauth aaa aaa
        probe_resistance myaaa.local
        serve_pac        /foraaa.pac
        response_timeout 30
        dial_timeout     30
    }
    root /var/www/html
    gzip
}

local proxy setting

:54086 {
    forwardproxy {
        response_timeout 30
        dial_timeout     30
        upstream  https://aaa:[email protected]:443
    }
    root /root/bin/caddy/html
}

4. How is your client configured?

curl --connect-timeout 5 -m 35 --proxy 127.0.0.1:54086 http://mydl.xyz.info/dl/aaa.txt

5. How did you run Caddy? (give the full command and describe the execution environment). If multiple servers are used (for example with upstream), describe those as well.

just start caddy from command line.

6. Please paste any relevant HTTP request(s) here.

curl --connect-timeout 5 -m 35 --proxy 127.0.0.1:54086 http://mydl.xyz.info/dl/aaa.txt

7. What did you expect to see?

download the aaa.txt and print it on console

8. What did you see instead (give full error messages and/or log)?

502 Bad Gateway

23/Aug/2018:15:57:54 +0800 [ERROR 502 /dl/aaa.txt] failed to read http response: http2: server sent GOAWAY and closed the connection; LastStreamID=5, ErrCode=NO_ERROR, debug=""
23/Aug/2018:16:08:34 +0800 [ERROR 502 /dl/aaa.txt] failed to read http response: read tcp 192.168.99.191:13532->199.xxx.xxx.249:443: i/o timeout
23/Aug/2018:16:10:50 +0800 [ERROR 502 /dl/aaa.txt] failed to read http response: read tcp 192.168.99.191:14490->199.xxx.xxx.249:443: i/o timeout

use strace on both side, I've found upstream caddy actually write the response

[pid 13885] write(9, "GET /dl/aaa.txt HTTP/1.1\r\nHost: 23.227.184.155\r\nUser-Agent: curl/7.52.1\r\nAccept: */*\r\nForwarded: for=\"127.0.0.1:33480\"\r\nVia: 1.1 caddy\r\n\r\n", 138) = 138
[pid 13885] write(8, "\27\3\3\0\0356\212\"\244\244\216 ~\246\254\25\242_L\2148\353s!k\272a\336\276/\33\10'x", 34) = 34
[pid 13885] write(8, "\27\3\3\0\35Vh\10\224\2\2529d\250\22[&\210\3k8\330\221\336\212\320\211\7\1V\363_?g", 34) = 34
[pid 13885] read(9, "HTTP/1.1 200 OK\r\nAccept-Ranges: bytes\r\nContent-Length: 8\r\nContent-Type: text/plain; charset=utf-8\r\nEtag: \"pdwlpn8\"\r\nLast-Modified: Thu, 23 Aug 2018 07:48:59 GMT\r\nServer: Caddy\r\nDate: Thu, 23 Aug 2018 08:23:06 GMT\r\n\r\nkillfbx\n", 32768) = 224
[pid 13885] write(8, "\27\3\3\0#\320\7\202\263\205\371A?C\222\371\36U\334\351#Xn\252\7J\324\205T\r\236%p \347m.5\253\260", 40 <unfinished ...>
[pid 13884] read(9, 0xc420684000, 32768) = -1 EAGAIN (Resource temporarily unavailable)
[pid 13885] <... write resumed> )       = 40
[pid 13884] read(8, "", 1024)           = 0
[pid 13884] write(8, "\25\3\3\0\22\272\345\177\262\24\324\33\257\34~\320\341e\247\330\346%2", 23) = 23
[pid 13880] shutdown(9, SHUT_WR)        = 0
[pid 13885] read(9, "", 32768)          = 0

and it seems local caddy has also received it

[pid  4305] write(6, "\27\3\3\0\243\315\252\307\367a\1\f\371\276Y\35vD\356D\240\275\347[\267\344Mj\336\240\242\265Ry%,\201z\305\17\353\37\201\255=\267,1=\334\310\20\7\3400\3]\354B\"1\223s\10\324=\\ \202\25\224>
\264\3712\331X\261\376\321\233\22\220-Q\7{}0\r\5\t\37\232\231a\310\310V\314\313G-)Zu-\343\275\34Wr6F\304?\177l\265\31?\364\fkk\"Z\2teS}\v%\274#\nuR\370G\310\245\261[\351\216p\2\365\10\227\244\212~M\240\307\347\216\6\273\370'@`H", 168) = 168
[pid  4331] read(6, "\27\3\3\0\0356\212\"\244\244\216 ~\246\254\25\242_L\2148\353s!k\272a\336\276/\33\10'x\27\3\3\0\35Vh\10\224\2\2529d\250\22[&\210\3k8\330\221\336\212\320\211\7\1V\363_?g", 1024) = 68
[pid  4331] read(6, 0xc4205b2000, 4096) = -1 EAGAIN (Resource temporarily unavailable)
[pid  4331] read(6, "\27\3\3\0#\320\7\202\263\205\371A?C\222\371\36U\334\351#Xn\252\7J\324\205T\r\236%p \347m.5\253\260", 4096) = 40
[pid  4331] read(6, 0xc4205b2000, 4096) = -1 EAGAIN (Resource temporarily unavailable)

but caddy don't think the request is finished.

9. How can someone who is starting from scratch reproduce the bug as minimally as possible?

use above config.

？？？？

Plugin isn't available?

Downloading Caddy for linux/amd64...
https://caddyserver.com/download/linux/amd64?plugins=http.forwardproxy
curl: (22) The requested URL returned error: 400 Bad Request
Aborted, error 22 in command: curl -fsSL "$caddy_url" -o "$dl"
The command '/bin/sh -c curl --fail https://getcaddy.com | bash -s http.forwardproxy' returned a non-zero code: 1
```

Currently, if the upstream proxy server supports only HTTP/2, forwardproxy can not work with it.
Could you please add support for connecting to HTTP/2 upstream proxy server?
Thank you!

Looks like it does.

I want to log incoming IP addresses, and as Caddy is in the container, I use http.realip for this. Requests are coming from AWS internal load balancer, which adds X-Forwarded-For, then they go outside.

I definitely don't want to forward X-Forwarded-For, and I have hide_ip enabled. Nevertheless, remote servers get my internal network IPs via X-Forwarded-For, which is not stripped from outgoing requests.

deny means visit the ip address or domain via proxy, it returns 404.
bypass means it connect to ip or domain directly, not via proxy.
please consider it.

Forwardproxy plugin does not prevent user from specifying unvisitable secret links in Caddyfile. Notably, "unvisitable" includes links with uppercase letters.
This also might apply to auto-generated pac files.

The link (https://sfrolov.io/2017/08/secure-web-proxy-client-en) to the blog post doesn't work, unfortunately. To be honest, from the documentation I can't figure out how to call the proxy properly.

1. What version of Caddy are you using (caddy -version)?

Caddy 0.11.0 (non-commercial use only)

2. What are you trying to do?

Use forwardproxy plugin to serve as a forward proxy.

3. What is your entire Caddyfile?

*.* {
 timeouts none
 tls *@*
 header / Strict-Transport-Security "max-age=31536000;"
# ...
 gzip
# ...
 proxy /ws 127.0.0.1:9613 {
  websocket
  header_upstream -Origin
 }
 forwardproxy {
  basicauth user passwd
  hide_ip
  hide_via
#  probe_resistance secretlink.localhost
  response_timeout 10
  dial_timeout     10
 }
}

4. How did you run Caddy (give the full command and describe the execution environment)?

./caddy --conf=/usr/local/caddy/Caddyfile -agree
centos 6.9 x64

5. Please paste any relevant HTTP request(s) here.

6. What did you expect to see?

7. What did you see instead (give full error messages and/or log)?

When I access https sites over the https proxy, it works fine. But for http site it shows 502 Bad Gateway in broswer.
Caddy's log here
01/Jul/2018:08:40:45 -0400 [ERROR 502 /favicon.ico] dial failed: Lookup of fai led: lookup : no such host 01/Jul/2018:08:40:46 -0400 [ERROR 502 /] dial failed: Lookup of failed: lookup : no such host 01/Jul/2018:08:40:51 -0400 [ERROR 502 /] dial failed: Lookup of failed: lookup : no such host 01/Jul/2018:08:40:53 -0400 [ERROR 502 /image] dial failed: Lookup of failed: l ookup : no such host 01/Jul/2018:08:40:54 -0400 [ERROR 502 /image] dial failed: Lookup of failed: l ookup : no such host 01/Jul/2018:08:40:54 -0400 [ERROR 502 /image] dial failed: Lookup of failed: l ookup : no such host 01/Jul/2018:08:40:54 -0400 [ERROR 502 /image] dial failed: Lookup of failed: l ookup : no such host 01/Jul/2018:08:40:54 -0400 [ERROR 502 /image] dial failed: Lookup of failed: l ookup : no such host 01/Jul/2018:08:40:54 -0400 [ERROR 502 /image] dial failed: Lookup of failed: l ookup : no such host 01/Jul/2018:08:40:54 -0400 [ERROR 502 /image] dial failed: Lookup of failed: l ookup : no such host
What surprised me most is that I have tested an exactly same caddyfile(except domain) on another server , also with caddy 0.11.0, and nothing like this happend.

8. How can someone who is starting from scratch reproduce the bug as minimally as possible?

1. Is bug reproducible with latest forwardproxy build?

yes.
on plugin version was build mtime: 2019-04-24 13:54:04.000000000 -0400

2. What are you trying to do?

Install Caddy with forwardproxy

3. What is your entire Caddyfile?

no

4. How is your client configured?

5. How did you run Caddy? (give the full command and describe the execution environment). If multiple servers are used (for example with upstream), describe those as well.

no

6. Please paste any relevant HTTP request(s) here.

no

7. What did you expect to see?

no

8. What did you see instead (give full error messages and/or log)?

no

9. How can someone who is starting from scratch reproduce the bug as minimally as possible?

https://caddyserver.com/download
choose linux-64bit,only forwardproxy plugin selected.
then click download